Hello all Since the VHDL variables topic strikes as a little bit odd even to VHDL designers who have some experience I would like to ask about VHDL variables in order to clarify a few things. If we have the usual case of register A feeding register B through some combinational logic (registers in same clock domain) then, until now,when I needed to make some complicated combinational code to represent the combinational code between the two registers, I used to do it in another non-clocked process having as inputs the outputs of register stage A and the outputs of the combinational code feeding the input of register stage B. Then inside the clocked process of stage B assign the values of the input. I was wondering, in order to make the code more readable and maintanable, is it possible to use variables to implement the complicated combinational code inside the clocked process so that I do not have to use another non-clocked process? Since I havent found somewhere a clear answer about the use of variables, I wanted to ask, is that the purpose of existence of VHDL variables? Do variables exist in order simplify the writing of combinational code inside a clocked process? Note: If I used signals inside the clocked process to help me store intermediate results,that would lead to register inference which is not intended if the designer wants to implement pure combionational code inside the clocked process.

--- Quote Start --- Hello all I was wondering, in order to make the code more readable and maintanable, is it possible to use variables to implement the complicated combinational code inside the clocked process so that I do not have to use another non-clocked process? Since I havent found somewhere a clear answer about the use of variables, I wanted to ask, is that the purpose of existence of VHDL variables? Do variables exist in order simplify the writing of combinational code inside a clocked process? Note: If I used signals inside the clocked process to help me store intermediate results,that would lead to register inference which is not intended if the designer wants to implement pure combionational code inside the clocked process. --- Quote End --- That is one of the 'great' uses of variables: splitting up a long series of complicated comb code inside a clocked process over multiple lines. The other use is: instead of declaring globally visible 'signals' which are only used in this process, you can declare variables locally and make them infer registers. You have perfect control whether a variable infers registers or not: if you assign to the variable first before 'reading' it, no registers will be inferred. I made a 'contrived' example: --variables.vhd library ieee ; use ieee.std_logic_1164.all ; use ieee.numeric_std.all ; entity variables is port( Clk : in std_logic; Reset : in std_logic; A : in natural range 0 to 255; B : in natural range 0 to 255; C : in natural range 0 to 255; Y : out natural range 0 to 1023 ); end variables; architecture arch of variables is begin process ( Clk , Reset ) is variable t1 : natural ; -- combinatorial variable t2 : natural ; -- registered begin if (Reset = '1') then Y <= 0 ; elsif rising_edge( Clk ) then Y <= t2 + C ; -- this will infer registers for t2 if (A > B) then t1 := A ; else t1 := B ; end if ; t2 := t1 + B ; end if; end process ; end arch ; If we run this through the Analysis & Synthesis we see the following in the RTL Viewer: see .pdf attached. You can see the combinatorial logic for 't1' and the inferred registers for 't2'.

You are right but I think it's a matter of readibility and avoiding mistakes. I find it more easy to read splitting the RTL into a combination process and a sequential process. So, no need for variable. when you need the _next value(comb) right away in the sequential process just use the LVALUE (next) in the decision making. It's always harder to spot errors in simulation using Variables and simulation/synthesis mismatch ocurrs more. YMMV

VHDL Variables: Is it combinational code inside a clocked process?

25 Replies

Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---
Hello all

I was wondering, in order to make the code more readable and maintanable, is it possible to use variables to implement the complicated combinational code inside the clocked process so that I do not have to use another non-clocked process?

Since I havent found somewhere a clear answer about the use of variables, I wanted to ask, is that the purpose of existence of VHDL variables? Do variables exist in order simplify the writing of combinational code inside a clocked process?

Note: If I used signals inside the clocked process to help me store intermediate results,that would lead to register inference which is not intended if the designer wants to implement pure combionational code inside the clocked process.
--- Quote End ---

That is one of the 'great' uses of variables: splitting up a long series of complicated comb code inside a clocked process over multiple lines. The other use is: instead of declaring globally visible 'signals' which are only used in this process, you can declare variables locally and make them infer registers.
You have perfect control whether a variable infers registers or not: if you assign to the variable first before 'reading' it, no registers will be inferred.
I made a 'contrived' example:
--variables.vhd library ieee ; use ieee.std_logic_1164.all ; use ieee.numeric_std.all ; entity variables is port( Clk : in std_logic; Reset : in std_logic; A : in natural range 0 to 255; B : in natural range 0 to 255; C : in natural range 0 to 255; Y : out natural range 0 to 1023 ); end variables; architecture arch of variables is begin process ( Clk , Reset ) is variable t1 : natural ; -- combinatorial variable t2 : natural ; -- registered begin if (Reset = '1') then Y <= 0 ; elsif rising_edge( Clk ) then Y <= t2 + C ; -- this will infer registers for t2 if (A > B) then t1 := A ; else t1 := B ; end if ; t2 := t1 + B ; end if; end process ; end arch ;

If we run this through the Analysis & Synthesis we see the following in the RTL Viewer: see .pdf attached.
You can see the combinatorial logic for 't1' and the inferred registers for 't2'.
Altera_Forum
Honored Contributor
11 years ago
No more to say!

Thanks a lot!
Altera_Forum
Honored Contributor
11 years ago
Oh. Another question came up though.

What happens when the designer wants to export asynchronously a variable from a clocked process?

Declaring a signal and assigning it to the variable inside the clocked process would infer a register...

I suppose doing the assignment after the "clocked" IF, ELSEIF(rising edge) would still keep the signal asynchronous...right?
Altera_Forum
Honored Contributor
11 years ago
You are right but I think it's a matter of readibility and avoiding mistakes.

I find it more easy to read splitting the RTL into a combination process and a sequential process. So, no need for variable. when you need the _next value(comb) right away in the sequential process just use the LVALUE (next) in the decision making.

It's always harder to spot errors in simulation using Variables and simulation/synthesis mismatch ocurrs more.

YMMV

Altera_Forum

Honored Contributor

11 years ago

--- Quote Start ---

Oh. Another question came up though.

What happens when the designer wants to export asynchronously a variable from a clocked process?

Declaring a signal and assigning it to the variable inside the clocked process would infer a register...

I suppose doing the assignment after the "clocked" IF, ELSEIF(rising edge) would still keep the signal asynchronous...right?

--- Quote End ---

No. I just modified my 'contrived' example to try this out.

--variables.vhd
library ieee ;
	use ieee.std_logic_1164.all ;
	use ieee.numeric_std.all ;
entity variables is
	port(
		Clk   : in  std_logic;
		Reset : in  std_logic;
		A     : in  natural range 0 to 255;
		B     : in  natural range 0 to 255;
		C     : in  natural range 0 to 255;
		Y     : out natural range 0 to 1023;
		Y5    : out natural range 0 to 255;
		Y2    : out natural range 0 to 255;
		Y3    : out natural range 0 to 511;
		Y4    : out natural range 0 to 1023
	);
end variables;
architecture arch of variables is
begin
	process ( Clk ,  Reset , A, B) is
			variable t0 : natural range 0 to 255 ;
			variable t1 : natural range 0 to 255 ;
			variable t2 : natural range 0 to 511 ;
			variable t4 :  natural range 0 to 255 ;
		begin
			if (Reset = '1') then
				Y <= 0 ;
				t2 := 0 ;
			elsif rising_edge( Clk ) then
				Y <= t2 + C ;
				if (A > B) then
					t1 := A ;
					t0 := B ;
				else
					t1 := B ;
					t0 := A ;
				end if ;
				t2 := t0 + B ;
			end if;
			Y2 <= t1 ;
			Y3 <= t2 ;
			Y4 <= t1 + t2 ;
			if (A > B) then
				t4 := A ;
			else
				t4 := B ;
			end if ;
			Y5 <= t4 ;
		end process ;
end arch ;

In variables3.pdf you can see what happens:

Altera_Forum
Honored Contributor
11 years ago
Why does t1 become a register?
Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---
Why does t1 become a register?
--- Quote End ---

Puzzles me too :)
It would have been very nice had it stayed combinatorial.
This may be one of the oddities Aprado hinted at. Modelsim may behave differently than Quartus II. Until now I've only used variables as I show in my first code example. (Playing safe)
Altera_Forum
Honored Contributor
11 years ago
Well it has to do with the involvement of t2. Did you get any warnings? Because t1 now has no reset value.

If you have put the assignment of t4 inside the clocked if (it would still be combinational) and assign it to Y5 outside the clocked if then would Y5 still be combinational?

By answering to this question i also solve the asynchronous propagation of my variables outside of the process (as soon as the variables do not interact with clocked variables or signals, as we saw here with t1 and t2)
Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---
Puzzles me too :)
It would have been very nice had it stayed combinatorial.
This may be one of the oddities Aprado hinted at. Modelsim may behave differently than Quartus II. Until now I've only used variables as I show in my first code example. (Playing safe)
--- Quote End ---

t1 is not register. It is y2 and y4 that are registered.
Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---
You are right but I think it's a matter of readibility and avoiding mistakes.

I find it more easy to read splitting the RTL into a combination process and a sequential process. So, no need for variable. when you need the _next value(comb) right away in the sequential process just use the LVALUE (next) in the decision making.

It's always harder to spot errors in simulation using Variables and simulation/synthesis mismatch ocurrs more.

YMMV
--- Quote End ---

I don't know of any mismatch between tools regarding variables as long as they conform to vhdl standards.
One case when I need to use variable is modulo n accumulator when n is not power of 2.
For example if I need to add 7 modulo 100. I need to prevent counter going > 99 so I need to use variable to check value of counter and force it:
variable count : integer range 0 to 99 := 0; begin ... if count > 99 then count := count -100; else count := count + 7; end if; ...

if you use signal then count will be > 99 for one sample. Here one cay use if (count + 7) > 99... but I prefer variable

Forum Discussion

VHDL Variables: Is it combinational code inside a clocked process?

25 Replies

Recent Discussions

Quartus messages web search goes to Intel

Duplicate_hierarchy_depth / duplicate_register

how to reduce clock skew between synchronous clock

Quartus - Users getting license Notification with new license applied

Is Quartus Prime Pro 22.4 Compatible with Stratix 10 NX Series Device 1SN21CEU2F55E2VG?