When to use temp variable over a signal in VHDL

[BlackHelicopter]

When would someone use a temp variable over a signal in VHDL? In VHDL I usually picture a signal as a wire connecting two points together(is this accurate?), what would the interpretation be for a temp variable and when would you use it over a signal?

 

[TrickyDicky]

This will come down to people's tastes, coding styles and religious ideals.

Given your question, I assume you understand the difference between the two (ie. signal updated when a process next suspends, variables updated immediatly).

There are two main coding styles I employ. The first is to use variables to add clarity to registers. So consider the following code (I know its fairly simple, but I hope you get the concept)

signal a : unsigned(7 downto 0);

process(clk)
begin
  if rising_edge(clk) then

    --do an addition with saturation logic
    if ('0' & x) + ('0' & y) > 255 then
      a <= to_unsigned(255, 8)
    else
      a <= x + y;
    end if;
  end if;
end process

A variable could be used to add some clarity to the code and make it easier to read:

process(clk)
  variable sum_temp : unsigned(8 downto 0);
begin
  if rising_edge(clk) then

    --do an addition 
    sum_temp := ('0' & x) + ('0' & y);

    if sum_temp > 255 then
      a <= to_unsigned(255, 8)
    else
      a <= sum_temp(7 downto 0);  --or x + y if you wish
    end if;
  end if;
end process;

This breaks the code down into smaller peices of logic on real hardware, and might make it easier for someone else to understand whats going on in your code. Both processes above will create the same logic, but is a little easier to read.

The second school of thought is to keep as many things within as local a scope as possible. This can help when you have millions of signals in a file - if you instead used local variables rather than signals, it becomes clearer what logic is generated in which process. You can infer regisers from variables just by putting the assignments in the correct order. So these two bits of code are the same:

  signal a,b,c,d : std_logic;

process(clk)
begin
  if rising_edge(clk) then
    a <= in;
    b <= a;
    c <= b;
    d <= c;
    out <= d;
  end if;
end process;


--second method using variables - produces the same logic;
process(clk)
  variable a,b,c,d : std_logic;
begin
  if rising_edge(clk) then
    out <= d;
    d := c;
    c := b;
    b := a
    a := in;
  end if;
end process;

So the advantage is if you have a lot of processes, and a lot of signals, the second method is clearer which signals belong in which process(because there are fewer of them) and you can keep using the same names in different processes for the local variables because of scoping rules. The disadvantage is that you have to be careful with code ordering, and many people get confused when you start using variables, because many people prefer the first coding style.

---------- Post added at 09:41 ---------- Previous post was at 08:36 ----------

So to summerise - both signals and variables are in effect just wires between logic. But its the context that is all important.

Welcome to behavioral HDL.

 

[FvM]

A more general application of variables is in cascaded operations like below

process(clk)
  variable a: unsigned[7 downto 0];
begin
  if rising_edge(clk) then
    a := <expression1>;
    if <cond1> then
      a := a +1;
    end if;
    if <cond2> then
      a := <expression2>;
    end if;
    sig1 <= a;
  end if;
end process;

Of course, this is a very behavioral representation of a problem which hasn't much to do with the finally synthesized logic. There may be serious doubts, if we should write VHDL this way, because it smells like C code. In my opinion, it's reasonable, if the code structure represents the real problem in a visual way and if it's technically required to process it in a single clock cycle. But we should keep in mind, that the construct generates complex combinational logic between registers and may cause timing issues.

 

[TrickyDicky]

There are some people who produce full designs in a software style: like this guy: Mike Treseler's Folder

This is a very advanced style and you really have to know what you're doing (but it looks alot more like software).

 

[permute]

I tend to use signals where possible. Mainly because signals must be used within the design, and it also allows each logical portion within a process to be approached separately. Every time I've used a signal outside of this, I've always ended up tracking down a logic error that resulted from it.

That said, variables can be used very sucessfully for some specific operations. They also force intermediate signals to be local to a process, and can result in significantly faster simulations for some simulators.

as for the linked code, I don't really like it as shown. The inconsistent indentation is annoying. The procedures almost never add anything over just a simple comment.

 

[BlackHelicopter]

Thank you very much TrickyDicky, FvM, and also Permute, the examples and explanations really help. This definitely cleared up a lot of confusion. Thanks.

---------- Post added at 04:47 ---------- Previous post was at 03:40 ----------

signal a : unsigned(7 downto 0);

process(clk)
begin
  if rising_edge(clk) then

    --do an addition with saturation logic
    if ('0' & x) + ('0' & y) > 255 then
      a <= to_unsigned(255, 8)
    else
      a <= x + y;
    end if;
  end if;
end process

Tricky, could you explain the use of the saturation logic in the adder, if x and y are both defined as lets say: in unsigned (7 downto 0), why not use x + y > 255 instead of ('0' & x) + ('0' & y) > 255? I'm guessing I'm missing something. (I know, has nothing to do with my original question, but had to ask).

 

[FvM]

in unsigned (7 downto 0), why not use x + y > 255 instead of ('0' & x) + ('0' & y) > 255?

The result of adding two 8 bit unsigned numbers is still 8 bit in size. It can't be > 255. You have to extend at least one addend before perfoming the addition to get a 9 bit result.