Which HDL do You Use?

[nctnico]

But what error do you get? At first sight it seems like some sort of type-clash to me.
From this page:
http://vhdl.renerta.com/mobile/source/vhd00014.htm

Code: [Select]

P5:process
variable Code_of_Operation : INTEGER range 0 to 2;
constant Variable_1 : INTEGER := 0;
begin
  C6: case Code_of_Operation is
      when Variable_1 | Variable_1 + 1 =>
      Operation := 0;
      when Variable_1 + 2 =>
      Operation := 1;
  end case C6;
end process;


[legacy]

ISE, ModelSim and ghdl: they all give the same error, and they don't accept constant as Case choice.
The example above smells "VHDL language improvement", new features may be

[nctnico]

I guess you already played with the VHDL 'version' settings 

[Sal Ammoniac]

One-hot encoding makes for simpler logic.

Is that always the case? The following article seems to imply that onehot encoding in FSMs leads to more complex logic.

http://www.sunburst-design.com/papers/CummingsSNUG2003SJ_SystemVerilogFSM.pdf

[Cerebus]

One-hot encoding makes for simpler logic.

Is that always the case? The following article seems to imply that onehot encoding in FSMs leads to more complex logic.

http://www.sunburst-design.com/papers/CummingsSNUG2003SJ_SystemVerilogFSM.pdf

Sometimes it will make for simpler logic, other times it'll make it worse.

An example of the "make it worse" case is something I wrote a few days ago. It's just a generator for half a dozen clocks that have to have a particular relationship to one another in time. The whole thing has 32 states. One clock is high for two of those, another two for 7 clocks each and so on. If you implement it as a counter and ROM, it's a doddle. If you implement it as 32 one hot states, it's a great big mess of OR gates, some 2 wide, some 7 and so on.

[Bassman59]

That is no surprise because an integer isn't really synthesizable. You should used signed and unsigned types for synthesizable logic.

I use naturals and integers all the time in synthesizable code. The trick is to specify a range for the integer, which does two things. One, in simulation, you get an error if you ever try to assign a number outside the range, you get an error.

Two, the synthesizer is smart enough to know to limit the number of flip-flops created for the signal. So if you have a signal declared as:

Code: [Select]

signal foo : natural range 0 to 100;
the synthesizer will infer a 7-bit register.

Counting and doing math with std_logic_vectors is to be avoided.

[rstofer]

Counting and doing math with std_logic_vectors is to be avoided.

Why is that?  I realize it takes the inclusion of a non-standard library but it sure saves a lot of casting.

Most of the tutorials I have seen use SLVs for everything.  I know I'm supposed to change and I'm trying but I really don't know why it matters.  In the end, everything is an SLV.

If the answer revolves around simulation, it's just an exercise because I don't use the simulator.  Simple projects and other ways to debug.

[Bassman59]

Counting and doing math with std_logic_vectors is to be avoided.

Why is that?  I realize it takes the inclusion of a non-standard library but it sure saves a lot of casting.

Why? Because we are humans and we do math with numbers, not with vectors of bits. Many times there is no need to do the casts, anyway. Counters, memory addresses, all sorts of things can remain ranged integers and never be converted to a bit-vector representation.

And yes, you can use naturals and integers on entity ports. (The exception, of course, is at the top level of your FPGA design.)

Most of the tutorials I have seen use SLVs for everything.  I know I'm supposed to change and I'm trying but I really don't know why it matters.  In the end, everything is an SLV.

The tutorials were written in the dark ages before synthesizers could deal with integers, and they've never been updated. Hell, some of them still write

Code: [Select]

if clk'event and clk = '1' then
Instead of

Code: [Select]

if rising_edge(clk) then
It would be nice if tutorials reflected the nice changes in the language since VHDL'93 ...

If the answer revolves around simulation, it's just an exercise because I don't use the simulator.  Simple projects and other ways to debug.

My projects are too complex to go without simulation.

You are free to code however you wish to code. But don't overlook the language's advantages.

[legacy]

Code: [Select]

if clk'event and clk = '1' then

even the Xilinx "ISE v10.1/State CAD" (a tool included with ISE) uses this obsolete form

[nctnico]

Counting and doing math with std_logic_vectors is to be avoided.

Why is that?  I realize it takes the inclusion of a non-standard library but it sure saves a lot of casting.

Most of the tutorials I have seen use SLVs for everything.

AFAIK the numerical library was added to VHDL 'later' and so using std_logic_vector stuck with many people. But nowadays you should use numeric types because it makes a lot of things easier (like doing calculations) or use a signal as an index for an array.

[Bassman59]

Code: [Select]

if clk'event and clk = '1' then

even the Xilinx "ISE v10.1/State CAD" (a tool included with ISE) uses this obsolete form

The language templates included with ISE 14.7 (the last version of ISE, from 2013) still use the obsolete idiom. The latest XST synthesis and style guide does use rising_edge(clk), though, as does the Vivado synthesis guide. Of course, they don't use the nice decorations, like labels for processes and such.

[Bassman59]

Counting and doing math with std_logic_vectors is to be avoided.

Why is that?  I realize it takes the inclusion of a non-standard library but it sure saves a lot of casting.

Most of the tutorials I have seen use SLVs for everything.

AFAIK the numerical library was added to VHDL 'later' and so using std_logic_vector stuck with many people. But nowadays you should use numeric types because it makes a lot of things easier (like doing calculations) or use a signal as an index for an array.

The original versions of VHDL did not allow for math operations on std_logic_vector types. You could do math on integer,  natural and real signals, but they weren't synthesizable (remember, this was 30 years ago!). Since most modeling was done using std_logic and its vector form std_logic_vector, Synopsys created a package, std_logic_arith, to define math operations on SLVs. A problem arises, which is how to handle unsigned and signed math, and the operators and functions were defined in packages std_logic_signed and std_logic_unsigned.

Synopsys decided that those decidedly non-standard libraries should be included in the ieee library, which is why you see it used as

use ieee.std_logic_arith.all;

instead of

use synopsys.std_logic_arith.all;

and it became the defacto standard.

A glaring problem emerges: what if you need to do unsigned and signed math in the same entity? What happens when you do:

use ieee.std_logic_arith.all;
use ieee.std_logic_signed.all;
use ieee.std_logic_signed.all;

and then you want to do some math:

signal foo : std_logic_vector(7 downto 0);
signal bar : std_logic_vector(7 downto 0);
signal bletch : std_logic_vector(7 downto 0);

bletch <= foo + bar;

Is that operation signed or unsigned? I honestly have no idea.

to that end, the IEEE came up with the package numeric_std, which, among other things defined the unsigned and signed types, all of the usual math operations on those types, as well as functions to sign- or zero-extend vectors (resize()) and convert between signed/unsigned and integers. (No conversion function is required to convert between signed or unsigned and std_logic_vector, as they are closely-related types, and all you need is a cast.)

Of course, synthesis tools have greatly improved since the gawd-awful Synopsys FPGA Express, and we can synthesize integers and naturals without issue.

And even though numeric_std was introduced in 1995, people still write code using the Synopsys packages. And worse, the IEEE gave up and made operations on SLVs standard as part of VHDL 2008 (requiring numeric_std_unsigned and numeric_std_signed).

[NorthGuy]

signal foo : std_logic_vector(7 downto 0);
signal bar : std_logic_vector(7 downto 0);
signal bletch : std_logic_vector(7 downto 0);

bletch <= foo + bar;

Is that operation signed or unsigned? I honestly have no idea.

The important thing is that whether it is signed or unsigned or any mix thereof, the result is exactly the same.

[romhunter]

Verilog for me. Both language feels the same, but I prefer something short since I'm a lazy ass guy. Verilog is surely shorter to write.