VHDL variables.

[GuilTy]

Hello,
 

Does anybody know how to use a variable in VHDL, that has the same behaviour like a static variable in C?


For example, I have an initial value which is 100. I subtract 10 from it and the new value is 90. But, then I want to substract 10 from the last value, which is 90, so the result will be 80, and so on.

I tried to save the result in an intermediate variable, but when I try to subtract the second time, the value is still 90. 


Thank you,
G

[dmills]

Take one addition operation and imply a register at the output, feed the register back to the adder.
Each time the process fires the register output will take the new value from the adder output, and the adder will get the new value from the register.

Regards, Dan.

[GuilTy]

And after the first rising edge of the clock, the initial value will update to the new value(which will come from the output of the register)? Is this what you are saying?


G

[rstofer]

Declaration
  variable addr_v : unsigned(addr_i'range);

Inside a clocked process
  addr_v := addr_v + BLOCK_SIZE_G;

[dmills]

Thats the one.

Regards, Dan.

[suicidaleggroll]

Hello,
 

Does anybody know how to use a variable in VHDL, that has the same behaviour like a static variable in C?


For example, I have an initial value which is 100. I subtract 10 from it and the new value is 90. But, then I want to substract 10 from the last value, which is 90, so the result will be 80, and so on.

I tried to save the result in an intermediate variable, but when I try to subtract the second time, the value is still 90. 


Thank you,
G

It works the same as in any other language (see rstofer's example), with one major caveat.  In a VHDL process, everything happens simultaneously.  This means that something like the following:

Code: [Select]

addr_v := addr_v + BLOCK_SIZE_G;
addr_v := addr_v + BLOCK_SIZE_G;will NOT add 2*BLOCK_SIZE_G, it will only do it once.  You can only update a variable once per clock cycle, if you want to add BLOCK_SIZE_G a second time, you need to do it on the next clock cycle.

[AndyC_772]

No, I don't think so; variables update immediately, so your example will indeed add 2*BLOCK_SIZE_G.

By contrast, signals only update on events (assuming the new value is assigned within a clocked process). A later assignment will supersede an earlier one.

[GuilTy]

Thank you all for your responses.

@suicidaleggroll, in a process things happen sequentially, not simulatenously.


G

[rstofer]

No, I don't think so; variables update immediately, so your example will indeed add 2*BLOCK_SIZE_G.

By contrast, signals only update on events (assuming the new value is assigned within a clocked process). A later assignment will supersede an earlier one.

I need to work on 'variables'.  I don't tend to use them (like never) because I don't understand how they are synthesized and simulation is not hardware.  Just a part of the universe I haven't explored.

Here is an incredibly good discussion of VHDL
http://www.utdallas.edu/~zxb107020/EE6306/Tutorial/VHDL.pdf

[Scrts]

I've always used unsigned and casted to variables if needed for bit indexing. This kept me out of these dilemmas 

[AndyC_772]

@suicidaleggroll, in a process things happen sequentially, not simulatenously.

Not really; in a process, things happen concurrently each time one of the signals in the process's sensitivity list changes.

If you say:

Code: [Select]

IF clk'event AND clk = '1' THEN
  b <= c;
  a <= b;
END IF;

... then both a and b take new values at exactly the same time. Signal 'a' will take its new value from whatever the value of 'b' was at the instant of the clock edge, not the new value (ie. the one equal to c).

Variables are different, though:

Code: [Select]

IF clk'event AND clk = '1' THEN
  b := c;
  a := b;
END IF;

In this case, on each edge, variables 'a' and 'b' will both get new values, and both will end up equal to c.

[suicidaleggroll]

No, I don't think so; variables update immediately, so your example will indeed add 2*BLOCK_SIZE_G.

By contrast, signals only update on events (assuming the new value is assigned within a clocked process). A later assignment will supersede an earlier one.

Sorry, I so rarely use variables that I didn't realize they behaved differently than signals in this regard.

[rstofer]

@suicidaleggroll, in a process things happen sequentially, not simulatenously.

Not really; in a process, things happen concurrently each time one of the signals in the process's sensitivity list changes.

If you say:

Code: [Select]

IF clk'event AND clk = '1' THEN
  b <= c;
  a <= b;
END IF;

... then both a and b take new values at exactly the same time. Signal 'a' will take its new value from whatever the value of 'b' was at the instant of the clock edge, not the new value (ie. the one equal to c).

Variables are different, though:

Code: [Select]

IF clk'event AND clk = '1' THEN
  b := c;
  a := b;
END IF;

In this case, on each edge, variables 'a' and 'b' will both get new values, and both will end up equal to c.

Thank you for the motivation to experiment a bit and thanks for the education I gained!

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity Variables is
    Port ( clk : in  STD_LOGIC;
           input : in  STD_LOGIC;
           W : out  STD_LOGIC;
           X : out  STD_LOGIC;
           Y : out  STD_LOGIC;
           Z : out  STD_LOGIC);
end Variables;

architecture Behavioral of Variables is

signal a,b : std_logic;
shared variable c,d : std_logic;

begin

W <= a;
X <= b;
Y <= c;
Z <= d;

process
begin
IF clk'event AND clk = '1' THEN
a <= input;
b <= a;
end if;

if clk'event AND clk = '1' then
c := input;
d := c;
end if;
end process;
end Behavioral;

After I synthesized the code, I took a look at the RTL schematic.  At all times, W, Y & Z are identical and simply the output of a single D-flop connected to input and clk.
Only X is clocked through 2 D-flops.

I just knew there was a reason I didn't use variables and I'll have to think carefully if I use them in my next project.  Variables are spooky!

Now I want to see what they do in a CASE statement when they appear in a case that isn't executed.  I see variables used instead of logic vectors for things like counters.  I don't see the motivation but I do see them used.  I need to do some more experiments.

[Neilm]

Generally, I only use variables in state machines and counters.

[AndyC_772]

I use them a lot to break down and clarify expressions that might be too long and complicated to easily read otherwise.

For example, suppose I have a 32-bit integer, and want to replace 8 bits of it with a byte that's been read in from elsewhere.

One way to do it would be to write:

Code: [Select]

VARIABLE v_long_integer : STD_LOGIC_VECTOR (31 DOWNTO 0);

v_long_integer := CONV_STD_LOGIC_VECTOR (long_integer, 32);
v_long_integer (15 DOWNTO 8) := CONV_STD_LOGIC_VECTOR (external_byte, 8);
long_integer <= CONV_INTEGER (UNSIGNED(v_long_integer));

These few lines of code simply indicate that bits 15..8 take a new value, and the rest remain unchanged. The actual logic that ends up getting synthesized is trivial. Inferring the correct logic without the use of variables is much more complex and difficult to express clearly.

[rstofer]

These few lines of code simply indicate that bits 15..8 take a new value, and the rest remain unchanged. The actual logic that ends up getting synthesized is trivial. Inferring the correct logic without the use of variables is much more complex and difficult to express clearly.

I tend to just use concatenation...

signal longvector : std_logic_vector(31 downto 0);
signal newdata : std_logic_vector(7 downto 0);


longvector <= longvector(31 downto 16) & newdata & longvector(7 downto 0);


I hope I didn't mess up the syntax!  Anyway, I tend to use the concat operator quite a bit.

And then there is Verilog.  I don't know anything about that language so I think I'll force myself to use it when I rewrite my CPU project for a newer chip.  Maybe after 10 or 20 thousand lines of code, I'll get the hang of it.

[rstofer]

These few lines of code simply indicate that bits 15..8 take a new value, and the rest remain unchanged. The actual logic that ends up getting synthesized is trivial. Inferring the correct logic without the use of variables is much more complex and difficult to express clearly.

I tend to just use concatenation...

signal longvector : std_logic_vector(31 downto 0);
signal newdata : std_logic_vector(7 downto 0);


longvector <= longvector(31 downto 16) & newdata & longvector(7 downto 0);


I hope I didn't mess up the syntax!  Anyway, I tend to use the concat operator quite a bit.

And then there is Verilog.  I don't know anything about that language so I think I'll force myself to use it when I rewrite my CPU project for a newer chip.  Maybe after 10 or 20 thousand lines of code, I'll get the hang of it.

The concatenation would have to be in a clocked process.  The variable approach wouldn't have to be clocked (AFAIK).

[AndyC_772]

Both are just different ways to express the same intent; there's no difference between how they'd behave.

I prefer the variable approach because it allows the assignment to be broken down into clear, individual steps:

- convert from integer type to vector
- replace some bits in the vector with the new value
- convert the new, updated vector back into an integer

In this example, the type conversion doesn't actually require any physical hardware - but it could.

My personal favourite use of variables in VHDL was to implement a CRC algorithm. The classical description of how to compute a CRC involves shifting the data a bit at a time into a shift register, and performing an XOR involving various taps (and the new data bit) to work out the value of the next bit to shift in.

This is all well and good, but it's not really much help if new data is available a byte at a time.

There's plenty of example code showing how to implement a byte-wide CRC, but it's not particularly readable. Big tables of magic numbers start appearing, and to someone familiar with the bit-at-a-time approach, the algorithm isn't immediately recognisable.

So, a nice trick to do in VHDL is to use variables, and to let the compiler do the hard work of figuring out how to deal with a whole byte at a time, given an algorithm that operates on a single bit at a time. Something like:

Code: [Select]

SIGNAL crc : STD_LOGIC_VECTOR (31 DOWNTO 0);
CONSTANT poly : STD_LOGIC_VECTOR (31 DOWNTO 0) := "10001...."; -- generator polynomial
SIGNAL new : STD_LOGIC_VECTOR (7 DOWNTO 0);

VARIABLE v_new_crc : STD_LOGIC_VECTOR (31 DOWNTO 0);
VARIABLE v_new_bit : STD_LOGIC;

IF clk'event AND clk = '1' THEN
  v_new_crc := crc;

  FOR i IN 0 TO 7 LOOP
    v_new_bit := new (i); -- pick out the next bit from our new data byte

    -- Step through the whole of the generator polynomial to find out where the taps are
    -- If there's a tap in a given position, XOR the new data bit with the shift reg contents

    FOR j IN 0 TO 31 LOOP
      IF poly (j) = '1' THEN
        v_new_bit := v_new_bit XOR v_new_crc (j);
      END IF;
    END IF;

    v_new_crc (31 DOWNTO 1) := v_new_crc (30 DOWNTO 0);
    v_new_crc (0) := v_new_bit;
  END LOOP;

  crc <= v_new_crc;
END IF;

I may have the details of the algorithm wrong, but I think as a way to illustrate the use of variables, it's still valid. What this code describes is a whole bunch of operations to be carried out on each clock edge, and the key thing to note is that on each edge there's exactly one assignment of a new value to a signal - namely, the update of signal 'crc' right at the end.

The new value of 'crc' is computed by following a sequence of steps incorporating a nested loop, and if it were being executed on a microprocessor core, it would be quite inefficient. But in VHDL, the meaning of that nested loop is evaluated at compile time, and the compiler's job is to work out a way to make the FPGA's hardware deliver the correct net end result.

Nothing in the FPGA actually iterates here. There's no state machine, and no sequence of steps that are actually executed one after the other.... just a single 32-bit value which is updated once per clock edge, based on the value of a data byte.

[exmadscientist]

Expanding on that theme, here's a chunk of VHDL that computes 32-bit CRCs on an entire 32-bit input word, which has the additional issue of dealing with byte ordering. This is a piece of production code I wrote a while back, which has been tested and verified with CRC-32 and CRC-32C checksums.

I really don't know how to write this sanely and readably without variables. Performance is excellent, because the synthesizer sorts out all the complicated logic and produces an implementation that gives you one word of output per clock.

Code: [Select]

-------------------------------------------------------------------------------
-- File        :  crc32.vhd
-- Description :  Generic 32-bit CRC calculator. Consumes one 32-bit input word
--                every clock, updating the output CRC value. Parameterized to
--                compute the major CRC variants encountered in the wild.
--
------------------------------------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

-------------------------------------------------------------------------------
-- Entity
-------------------------------------------------------------------------------
entity crc32 is
generic (
    -- Default parameters are for the standard "CRC-32" (IEEE 802.3) algorithm
    POLY      : std_logic_vector(31 downto 0) := X"04C11DB7";
    XORIN     : std_logic_vector(31 downto 0) := X"FFFFFFFF";
    XOROUT    : std_logic_vector(31 downto 0) := X"FFFFFFFF";
    REFLECTIN : boolean := true;
    REFLECTOUT: boolean := true
);
port (
    clk       : in  std_logic;
    reset     : in  std_logic;
    ena       : in  std_logic;
    data      : in  std_logic_vector(31 downto 0);
    crc       : out std_logic_vector(31 downto 0)
);
end entity crc32;

-------------------------------------------------------------------------------
-- Architecture
-------------------------------------------------------------------------------
architecture rtl of crc32 is

signal crc_i           : std_logic_vector(31 downto 0);
signal crc_i_reflected : std_logic_vector(31 downto 0);
   
begin

    pr_crc32 : process (clk)
    variable v_fb    : std_logic_vector(31 downto 0);
    variable crc_reg : std_logic_vector(31 downto 0);
    variable crc0    : std_logic;
    begin
        if (rising_edge(clk)) then

            if (reset = '1') then
                crc_reg := XORIN;
                crc_i <= crc_reg;
               
            else
                if (ena = '1') then

                    --For each bit in the input, calculate the serial CRC.
                    --Always consume LSByte first in CRC calculations.
                    if REFLECTIN then
                        --Reflected bit order:
                        --Consume the LSBit of each byte first.
                        for bit_idx in 0 to 31 loop
                            crc0 := crc_reg(31);
                            crc_reg := (crc_reg(30 downto 0) & '0');
                            if (crc0 /= data(bit_idx)) then
                                crc_reg := crc_reg xor POLY;
                            end if;
                        end loop;
                    else
                        --Normal bit order:
                        --We still consume the least significant byte first,
                        --  but bit order within each byte is reversed to
                        --  consume the MSBit first.
                        for byte_idx in 0 to 3 loop
                            for bit_idx in 7 downto 0 loop
                                crc0 := crc_reg(31);
                                crc_reg := (crc_reg(30 downto 0) & '0');
                                if (crc0 /= data(8*byte_idx + bit_idx)) then
                                    crc_reg := crc_reg xor POLY;
                                end if;
                            end loop;
                        end loop;
                    end if;
                   
                    crc_i <= crc_reg;

                end if;
            end if;
        end if;
    end process pr_crc32;

    g_reversed_output: for i in 0 to 31 generate
        crc_i_reflected(31-i) <= crc_i(i);
    end generate;
    crc <= crc_i_reflected xor XOROUT when REFLECTOUT
           else crc_i xor XOROUT;

end architecture rtl;


[rstofer]

OK guys!  I give...

You are both way above my pay grade!.  Now I'll have to spend a couple of hours coding this up and seeing how it synthesizes.  So much to learn, so little time...

[GuilTy]

I wish I had found this pdf earlier.

Here is an incredibly good discussion of VHDL
http://www.utdallas.edu/~zxb107020/EE6306/Tutorial/VHDL.pdf

Gracias

[tggzzz]

Does anybody know how to use a variable in VHDL, that has the same behaviour like a static variable in C?

That kind of question is always worrying.

With any new language it is necessary to understand what that language means by certain words. Doubly so for the differences between procesural software languages and hardware description languages.

[GuilTy]

Does anybody know how to use a variable in VHDL, that has the same behaviour like a static variable in C?

That kind of question is always worrying.

With any new language it is necessary to understand what that language means by certain words. Doubly so for the differences between procesural software languages and hardware description languages.

Do you have any good documentation about VHDL?

[jahonen]

I use variables if I have something which is purely local thing for a process. It makes things less cluttered as signals are then always for things which are shared between processes. It also makes it easy to duplicate the process if necessary without adding any extra clutter, say, in generate context.

I think that synthesis is pretty clear. With signals one can only access the registered version of the value (if value is assigned by clocked process), or give new value to the input of the register in question.

But with variables, if one reads the variable value before changing it in a clocked process, then it is like in signal case, output of a register. But if value of a variable is read (or used in any way) after it is changed, then it is the result from the combination logic feeding that register (simple?). So I think there is nothing inherently bad about using them on an actual hardware, if used correctly. Of course, abuse is easier with variables.

Regards,
Janne

[tggzzz]

Does anybody know how to use a variable in VHDL, that has the same behaviour like a static variable in C?

That kind of question is always worrying.

With any new language it is necessary to understand what that language means by certain words. Doubly so for the differences between procesural software languages and hardware description languages.

Do you have any good documentation about VHDL?

I have around 20 bookmarks which have been useful to me in the past. All were found by googling for what I needed to know at the time. Some have been mentioned here already, some may be dead links by now.

It very much depends on what you need for your next problem. I would suggest you start looking for "style guides" or "primers" or "FAQs" and similar, and then understand why they recommend that style.

[GuilTy]

But with variables, if one reads the variable value before changing it in a clocked process, then it is like in signal case, output of a register. But if value of a variable is read (or used in any way) after it is changed, then it is the result from the combination logic feeding that register (simple?). So I think there is nothing inherently bad about using them on an actual hardware, if used correctly. Of course, abuse is easier with variables.

It makes more sense now. As I said, I'm new to VHDL.

I have around 20 bookmarks which have been useful to me in the past. All were found by googling for what I needed to know at the time. Some have been mentioned here already, some may be dead links by now.

It very much depends on what you need for your next problem. I would suggest you start looking for "style guides" or "primers" or "FAQs" and similar, and then understand why they recommend that style.

I find your advice useful. It's way simpler to search for a specific thing.

Thanks to the both of you,

G

[blackbird]

Do you have any good documentation about VHDL?

Besides the numerous websites I've bookmarked myself, I have two hard copies of VHDL books:

Digital System Design with VHDL by Mark Zwolinski.
This one I would not recommend to start with VHDL (I had to buy this one as one of my first books at uni)

Circuit Design and Simulation with VHDL by Volnei Pedroni.
This is a much better one, to my opinion suitable for starters. Had to buy this one for my second year at uni.

If you search long enough you can find these digitally on the web although I strongly recommend to have a hard copy (at least of the second one).

[GuilTy]

Besides the numerous websites I've bookmarked myself, I have two hard copies of VHDL books:

Digital System Design with VHDL by Mark Zwolinski.
This one I would not recommend to start with VHDL (I had to buy this one as one of my first books at uni)

Circuit Design and Simulation with VHDL by Volnei Pedroni.
This is a much better one, to my opinion suitable for starters. Had to buy this one for my second year at uni.

If you search long enough you can find these digitally on the web although I strongly recommend to have a hard copy (at least of the second one).

Thank you. Now I'm reading "FPGA PROTOTYPING BY VHDL EXAMPLES " by Pong P. Chu. Maybe it will help someone else too.


G