Which HDL do You Use?

[nctnico]

monkey do is hardly a valid argument

like yours on integers, I suppose.

Just read about the pros and cons and you'll see using the signed and unsigned types is much better if you want the synthesize your VHDL code. Banging your head agains't the wall won't make it move but you will get a headache.

[legacy]

Just read about the pros and cons and you'll see using the signed and unsigned types is much better if you want the synthesize your VHDL code. Banging your head agains't the wall won't make it move but you will get a headache.

 

Dude, all bullshit until you give precise points.

[ehughes]

It still doesn't prove there is a better way today.

It's called SystemVerilog.      You get much better verification tools,  simpler synthesis constructs to convey intent and better support for specification of complex interfaces.     

That and my other objection to VHDL is that it was created by the US DoD.  The king of most inefficient systems engineering on the planet.  Combine the DoD with Academia and you end up with a monstrosity.

Can it do some cool things?  Yea.    Is it the most practical way to solve a problem.  No.

[nctnico]

Just read about the pros and cons and you'll see using the signed and unsigned types is much better if you want the synthesize your VHDL code. Banging your head agains't the wall won't make it move but you will get a headache.

 

Dude, all bullshit until you give precise points.

Why should *I* provide precise points if you clearly have a working internet connection and access to Google? Just take the pointers and do the research yourself.

[Sal Ammoniac]

It's called SystemVerilog.      You get much better verification tools,  simpler synthesis constructs to convey intent and better support for specification of complex interfaces.

How mature is SystemVerilog support in Vivado 2017.2? Is it mature enough for production use?

[ehughes]

How mature is SystemVerilog support in Vivado 2017.2? Is it mature enough for production use?

Yes.

[legacy]

Nice

which tool-set do you use for it?
(simulator, compiler, analyzer, editor, etc)

[obiwanjacobi]

As a beginner hobbyist learned VHDL, but I found it frustratingly verbose. Thinking of how I would design a hardware language, SystemVerilog came closest and so I am trying to switch to that (on my next project).

As with any hardware language, the learning curve is considerable.

[chris_leyson]

VHDL here, only because I couldn't get my head around Verilog syntax, I guess it wouldn't hurt to make the effort to learn Verilog.

[legacy]

and 'right'? Doesn't make sense. What would you use them for?

in first place the language MUST be consistent.
integers is a datatype, thus it MUST have the same property of other data-types.

in second place, upper and lower borders are useful when you give them a sub-range
it's very very useful when you describe something that aims to be generic

e.g. you have a counter under the sub-range of {min .. max}, and you want to write a loop.
If borders of integers are not supported by some tool (VHDL as language has it, ModelSim does support it, ISE doesn't), then you end with something that needs to have an explicit constant declared somewhere in the code

and this is more error-prone.

[legacy]

Code: [Select]

for i in in_data'range loop

if in_data is described as unsigned or std_logic_vector, then ISE accepts the 'range operator!
look at the code, how beautiful it goes!

you might want to do the same with integers to describe a counter!

[legacy]

It seems that Verilog is more used in ASIC than VHDL in the same business area thanks to its property of being able to offer functional coverage with less effort

interesting 

[Cerebus]

It seems that Verilog is more used in ASIC than VHDL in the same business area thanks to its property of being able to offer functional coverage with less effort

interesting 

I suspect that the relative popularity of Verilog in ASIC design is more down to the fact that Verilog has always had better support for timing than VHDL, so much so that in the first iterations of both languages Verilog had fully formed back annotation of timing, VHDL had none, nada, zip. Then consider how ASIC designers like to do little timing tricks (series of buffers as delay lines, combinatorial feedback etc.) and it becomes clear that VHDL would have, at first, been virtually unusable for ASIC simulation and sign-off.

[legacy]

Code: [Select]

for i in in_data'range loop

About the above property

Code: [Select]

  constant tick              : integer := (clock_frequency/debounce_frequency);
  signal   tick_counter      : integer range 0 to tick;

I am working on it just right now, here it is an example of what I find useful for me

[NorthGuy]

It would be interesting to know what the two people who voted "Something Else" are using.

[hamster_nz]

Code: [Select]

  constant tick              : integer := (clock_frequency/debounce_frequency);
  signal   tick_counter      : integer range 0 to tick;

I am working on it just right now, here it is an example of what I find useful for me

One thing I have yet to experiment with is the utility of this...

With using integer:

- Does it help during simulation/verification? 

- Does it ensure that tick_counter stays within range. (not sure, but I guess it should at least warn you during simulation)

- Does it enforce that it stays within the allowed range? e.g. if tick was 100, would the counter count 99, 100, 0 if the code was increment it?

- What is the point of an tick being integer if it doesn't go negative? Will it still have a sign bit? If you accidentally subtract 1 from 0, will it be -1?

- If you were worried about undefined reset states, or SEUs doesn't it hide too much to know the possible states?

- Aren't you relying on the smarts of the tools deduce the allowable range, dropping bits as needed:

I guess what I am asking is... do you still need to code something like:

Code: [Select]

  if tick_counter >= tick_counter'high then
   tick_counter <= 0;
  else
    tick_counter <= tick_counter+1;
  end if;

or can you code it like this:

Code: [Select]

    tick_counter <= tick_counter+1;  -- wraps at tick_counter'high

What (if anything) is wrong with:

Code: [Select]

  constant tick_counter_max : unsigned(31 downto 0) := unsigned(clock_frequency/debounce_frequency-1,32);
  signal   tick_counter          : unsigned(31 downto 0) := (others => '0')

  ...
  if tick_counter >= tick_counter_max then
   tick_counter <= 0;
  else
    tick_counter <= tick_counter+1;
  end if;
  ...


PS. Shouldn't it be:

Code: [Select]

  signal   tick_counter      : integer range 0 to tick-1;

(not that it really matters)

[hamster_nz]

One thing I have yet to experiment with is the utility of this...

With using integer:

- Does it help during simulation/verification? 

- Does it ensure that tick_counter stays within range. (not sure, but I guess it should at least warn you during simulation)

- Does it enforce that it stays within the allowed range? e.g. if tick was 100, would the counter count 99, 100, 0 if the code was increment it?

- What is the point of an tick being integer if it doesn't go negative? Will it still have a sign bit? If you accidentally subtract 1 from 0, will it be -1?

- If you were worried about undefined reset states, or SEUs doesn't it hide too much to know the possible states?

- Aren't you relying on the smarts of the tools deduce the allowable range, dropping bits as needed:

I guess what I am asking is... do you still need to code something like:

Code: [Select]

  if tick_counter >= tick_counter'high then
   tick_counter <= 0;
  else
    tick_counter <= tick_counter+1;
  end if;

or can you code it like this:

Code: [Select]

    tick_counter <= tick_counter+1;  -- wraps at tick_counter'high


So I fired up Vivado, and got an integer counter with range 0 to 100 and incremented it. after 3ms it was 299,998... with no warnings... humm.. where is the utility in that? 

[legacy]

- Does it help during simulation/verification? 

yes

- Does it ensure that tick_counter stays within range. (not sure, but I guess it should at least warn you during simulation)

With ModelSim you always get "bond error" (severity level -> simulation halted) if an integers/positive/natural goes out of the range.

- What is the point of an tick being integer if it doesn't go negative? Will it still have a sign bit? If you accidentally subtract 1 from 0, will it be -1?

Do you prefer "natural" or "positive" ? Of course, if you can use it: integers is signed, and it's 32 bit range. Positive is unsigned 32bit. If someone needs a huge counter, he/she had better use a sub range of positive.

- If you were worried about undefined reset states, or SEUs doesn't it hide too much to know the possible states?

No because
- everything (even integers) is pre-initialized once declared, signal blablabla := INIT_VALUE;
- counters are integers, everything else is handled with "std_logic_vector" and "unsignend"
- they both propagate X and U status, and you can see and react to mistakes from the simulator

Nothing is hidden, the there is always a starting value for counters! It's the fist thing I check when I simulate.

Aren't you relying on the smarts of the tools deduce the allowable range, dropping bits as needed:

well, I wrote a simple VHDL parser as "analyzer", and it was relatively easy to read a integer signal, look at its range, and deduce how many bits it takes

x=get_abs_max(range_min, range_max) ==> n_bit=get_log2(x);

ModelSim is even smarter than my simple tool by several and several orders of magnitude, and so it's ISE.


my code looks like this, anyway

Code: [Select]

    if rising_edge(in_clock) then
      if state = idle then       
      else
        if tick_counter=tick then
          tick_counter<=0;
        else
          tick_counter <= tick_counter+1;
        end if;
      end if;


Code: [Select]

constant tick            : integer := clk_freq/baudrate;
signal   tick_counter    : integer range 0 to tick;   

[..]

        if tick_counter=tick then

It's a reload-to-zero trick, there is no 'high because ISE is not able to understand it, thus this solution works for both ModelSim and ISE.

In my experience, it's better using a "compare_equal" rather than "compare_less_than"

[legacy]

where is the utility in that? 

Code: [Select]

error: bound check failed (#2), simulation failed

Next line of the log-console says which line of which file of code got the bound-checked failed.
So, you know where you have to look at.

[hamster_nz]

Ah! Found it!

For Vivado the default for Tools/Settings/Simuation xsim.elaborate.rangecheck is off. With it on it now it stops the sim when it should. That at least makes it useful for that.

In my experience, it's better using a "compare_equal" rather than "compare_less_than"

I tend to use >= in counters posted to the web, after being bitten a few times...

Code: [Select]

    if count = limit then
       count <= 0
    else
       count <= count + 1;
    end if;

Imagine the case when count is 20 bits (0 to ~1 million) as is 'limit', and limit dynamically changes - e.g. it is an input parameter to the module.

If 'limit' goes from 99 to 999 all is fine. If 'limit' changes from 999 to 99 then you have a 90% chance of the counter counting up all the way up to 2^20-1 before it cycles back to 0.

I'm happy to use that as a generic pattern, swapping a handful of LUTs for one less bug to hunt down after requirements change, making a 'constant' now not-so-constant....

[legacy]

Yup, for dynamic parameters your trick is better; here I am on a static parameters, I am designing the keyboard controller, counters are used to scan the matrix, perform debounces, transmit character (uart like).

All static parameters for counters 


edit:
p.s.
what about YOU, guys on Verilog?

[legacy]

another annoying thing in VHDL is that case's choices must be a locally static expression, you can't define a constant and use it 

Code: [Select]

      case matrix_in1 is
        when event_none  => datakey2 <= get_datakey(0);
        when event_key01 => datakey2 <= get_datakey(1);

not good

Code: [Select]

      case matrix_in1 is
        when b"00000000000000000" => datakey2 <= get_datakey(0);
        when b"00000000000000001" => datakey2 <= get_datakey(1);

good

[nctnico]

another annoying thing in VHDL is that case's choices must be a locally static expression, you can't define a constant and use it 

Code: [Select]

      case matrix_in1 is
        when event_none  => datakey2 <= get_datakey(0);
        when event_key01 => datakey2 <= get_datakey(1);

not good

Code: [Select]

      case matrix_in1 is
        when b"00000000000000000" => datakey2 <= get_datakey(0);
        when b"00000000000000001" => datakey2 <= get_datakey(1);

good

Ofcourse you can. Google VHDL enumerations: http://insights.sigasi.com/tech/vhdl-case-statements-can-do-without-others.html
An advantage of using an enumeration is that the synthesizer can select between one-hot or binary encoding. One-hot encoding makes for simpler logic.

[legacy]

Ofcourse you can

I am not talking about

Code: [Select]

type state_t is (s1, s2, s3);
signal state: case_t;
case state
  when s1 =>

I am talking about

Code: [Select]

constant event_key01 := get_matrix_in(1);

case matrix_in
  when event_key =>

VHDL doesn't allow this!

[legacy]

in VHDL (and this is a big mistake) enumeration is NOT equal to constant

thus VHDL claims that case choices MUST be a locally static expression

enumeration is static expression, thus accepted
BUT! formally even a constant is a static expression

The conclusion is:
VHDL, as language, is NOT consistent