sharing blogs about"rising_edge vs clk'event"and "numeric_std vs std_logic_arith"

[naught]

sharing blogs about"rising_edge vs clk'event"and "numeric_std vs std_logic_arith"

I have recently learned (yeah, thanks to the edaboard guys~) that some better ways to design my project, like using the rising_edge instead of clk'event, and using the library numeric_std instead of std_logic_arith.
These are two blogs from the vhdlguru that I think explains these issues well.

Difference between rising_edge(clk) and (clk'event and clk='1')
https://vhdlguru.blogspot.com/2010/04/difference-between-risingedgeclk-and.html

Why the library "numeric_std" is preferred over "std_logic_arith" and others?
https://vhdlguru.blogspot.com/2010/03/why-library-numericstd-is-preferred.html


the problems are all the people around me are using the std_logic_arith... I guess I have to blend in...

 

[permute]

Re: sharing blogs about"rising_edge vs clk'event"and "numeric_std vs std_logic_arith"

The numeric_std argument is actually more interesting when you research it a bit more. The highlights:

* in the 1990's, multiple companies made their own versions of "std_logic_arith/signed/unsigned". Of course for FPGA design this isn't important as all vendors are known to support the synopsys-based std_logic_arith/signed/unsigned.

* the vendors also had special hooks in their build tools that allowed the math to be sythesized optimally only when the correct library was used. Of course, the FPGA tools don't have this issue and clearly support both.

* VHDL actually treats slv as unsigned-ish in comparisons (when vectors are equal length). The default vector compare checks the leftmost bits until there is a difference. The std_logic's values are enumerated for their comparison, and '0' is less than '1', though 'Z' is greater than '1'. This has issues as "1000" < "11".

* std_logic_signed (or std_logic_unsigned) do not conflict* with numeric_std in practice. (there is an issue with "=" being redefined. The LRM claims that the redefinition should render both definitions invalid, though actual parsers will choose the most recent declaration).

* you can cherry-pick operators/functions from the libraries. eg, std_logic_signed."+" and std_logic_signed."-". Failing that, you could write your own "+" and "-" operators for slv's to allow addition/subtraction as logic operations. Doing this gets you the ability to do +/- on slv's where signed/unsigned doesn't matter.

* for some reason, you can and/or/xor unsigned values. Seems a bit odd that this didn't extend to allowing addition/subtraction of slv's...

* addition/subtraction can be legitimate logical operators. eg, (-x) and (x). (-x) xnor (x). etc...

* signed/unsigned are often a poor choice for the type of a signal. eg, fifo pointers have sequential ordering. calling them signed/unsigned would imply you could compare them in a meaningful way using ">". This is not the case.

* Verilog is very popular and people routinely accept the "unsigned-default" representation without issue.

* While you can make unsigned/signed ports in VHDL, this still doesn't remove all of the typecasting micromanagement.

* the linked blog is wrong -- std_logic_arith does not defined operations on slv's. That is done using std_logic_unsigned or std_logic_signed.

* there is so much backlash from some people that anything short of stock numeric_std only will result in them lecturing you about the evils of std_logic_arith.


My preferred style allows addition/subtraction/negation with slv. Something becomes signed/unsigned only if it is multiplied, compared lesser/greater, or if it actually represents a signed value. I tend to avoid ">=" when a simple "=" will work. As a result, I don't litter my code with type conversions unless they actually matter.

For the fifo-pointer example, I actually find myself using integer variables more often. This is partially due to synthesizer quirks when inferring block rams.

 

[K-J]

Re: sharing blogs about"rising_edge vs clk'event"and "numeric_std vs std_logic_arith"

* VHDL actually treats slv as unsigned-ish in comparisons (when vectors are equal length). The default vector compare checks the leftmost bits until there is a difference. The std_logic's values are enumerated for their comparison, and '0' is less than '1', though 'Z' is greater than '1'. This has issues as "1000" < "11".

That comparison is more like comparing two strings than it is comparing two unsigneds.

* for some reason, you can and/or/xor unsigned values. Seems a bit odd that this didn't extend to allowing addition/subtraction of slv's...

Not at all odd since there are two numeric interpretations, not one.

* While you can make unsigned/signed ports in VHDL, this still doesn't remove all of the typecasting micromanagement.

Using the correct type will minimize type casting and make code more readable. Whether it removes 'all' or not is not terribly important.

My preferred style allows addition/subtraction/negation with slv. Something becomes signed/unsigned only if it is multiplied, compared lesser/greater, or if it actually represents a signed value.

Then you're implicitly using a particular numeric representation rather than explicitly doing so...that does no favors for somebody else trying to use/support that code down the road.

I tend to avoid ">=" when a simple "=" will work.

Then you're missing out on some logic optimizations

As a result, I don't litter my code with type conversions unless they actually matter.

If one uses the correct data type the code isn't littered either.

For the fifo-pointer example, I actually find myself using integer variables more often. This is partially due to synthesizer quirks when inferring block rams.

Actually it has nothing to do with any synthesizer quirks. The reason is because memory/pointer based fifos will ultimately define an array of things to represent the memory. In order to access a particular memory element (i.e. Mem(xyz)), the VHDL language requires that 'xyz' be an integer.

Kevin Jennings

 

[permute]

Re: sharing blogs about"rising_edge vs clk'event"and "numeric_std vs std_logic_arith"

Using the correct type will minimize type casting and make code more readable.

There are several arguments against that point.

Then you're missing out on some logic optimizations

compare equal infers a nested LUT tree with depth log6(N) (for 6LUTs). compare greater infers something on the order of an adder in complexity.

Then you're implicitly using a particular numeric representation rather than explicitly doing so...that does no favors for somebody else trying to use/support that code down the road.

If someone had issues with seeing something like "cnt <= cnt + 1;" where cnt is never compared greater/less or multiplied, I would want to know. I would want to fire that person.

Actually it has nothing to do with any synthesizer quirks.

the fifo synthesizer quirks are due to versions of xst treating "dout <= ram(x/4);" differently than "y:=x; dout <= ram;". The latter infers a ram, the former infers registers. (possibly fixed in newer versions)

 

[mrflibble]

Re: sharing blogs about"rising_edge vs clk'event"and "numeric_std vs std_logic_arith"

If someone had issues with seeing something like "cnt <= cnt + 1;" where cnt is never compared greater/less or multiplied, I would want to know. I would want to fire that person.

Darnit, I just got virtually fired in a hypothetical scenario.

I have issues with "cnt <= cnt + 1;". The issues are that I prefer "cnt <= cnt + 1'd1;" since the latter prevents having yet another warning about "result width blah blah" cluttering up the synthesis output.


Edit: do I get double virtually fired for bringing up a verilog synthesis point in a vhdl discussion? Or did I get lucky and does vhdl throw a similar warning due to bit widths?

 

[K-J]

Re: sharing blogs about"rising_edge vs clk'event"and "numeric_std vs std_logic_arith"

There are several arguments against that point.

You haven't made such an argument here...but to head one off, we can just agree that we have different positions on this point

compare equal infers a nested LUT tree with depth log6(N) (for 6LUTs). compare greater infers something on the order of an adder in complexity.

Not generally true. Consider a four bit unsigned counter (i.e. cnt: unsigned(3 downto 0)) that is part of some bigger 'thing'. Now let's say under some conditions you want this counter to count from 0 to 8 and then reset back. According to your methodology you would code it like this...

if (cnt = 8) then
   cnt <= 0;
else
   cnt <= cnt + 1;
end if;

Whereas, if you coded it like this...

if (cnt >= 8) then
   cnt <= 0;
else
   cnt <= cnt + 1;
end if;

You would use less logic with the 'cnt >= 8' since the >= allows for optimizations that are not available to the =. Specifically, >= 8 will reduce to checking to see if cnt(3) = 1 but =8 would need to compare all four bits of cnt. Using > or < does not necessarily chew up more logic. Try it and see.

Kevin Jennings

 

[permute]

Re: sharing blogs about&quot;rising_edge vs clk'event&quot;and &quot;numeric_std vs std_logic_arith&quot;

That was a good point about some of the comparisons. I might check to see how well XST actually does. I've had a lot of issues where it doesn't pick up some obvious optimizations.

Edit: do I get double virtually fired for bringing up a verilog synthesis point in a vhdl discussion? Or did I get lucky and does vhdl throw a similar warning due to bit widths?

VHDL throws an error if "cnt" is defined as a std_logic_vector (a reg/net in verilog) instead of an unsigned/signed (an unsigned reg, unsigned net, signed reg, signed net for verilog). VHDL also throws an error if you try to assign an unsigned to a slv, or an slv to an unsigned. Of course this is only true if you use the numeric_std library as-is -- there are other options including simply writing wrappers around numeric_std to handle the slv+int, slv+slv, etc...

- - - Updated - - -

That was a good point about some of the comparisons. I might check to see how well XST actually does. I've had a lot of issues where it doesn't pick up some obvious optimizations.

Edit: do I get double virtually fired for bringing up a verilog synthesis point in a vhdl discussion? Or did I get lucky and does vhdl throw a similar warning due to bit widths?

VHDL throws an error if "cnt" is defined as a std_logic_vector (a reg/net in verilog) instead of an unsigned/signed (an unsigned reg, unsigned net, signed reg, signed net for verilog). VHDL also throws an error if you try to assign an unsigned to a slv, or an slv to an unsigned. Of course this is only true if you use the numeric_std library as-is -- there are other options including simply writing wrappers around numeric_std to handle the slv+int, slv+slv, etc...

 

[TrickyDicky]

Re: sharing blogs about&quot;rising_edge vs clk'event&quot;and &quot;numeric_std vs std_logic_arith&quot;

VHDL throws an error if "cnt" is defined as a std_logic_vector (a reg/net in verilog) instead of an unsigned/signed (an unsigned reg, unsigned net, signed reg, signed net for verilog). VHDL also throws an error if you try to assign an unsigned to a slv, or an slv to an unsigned. Of course this is only true if you use the numeric_std library as-is -- there are other options including simply writing wrappers around numeric_std to handle the slv+int, slv+slv, etc...

This makes me think you try and fight the language rather than work with it.

 

[permute]

Re: sharing blogs about"rising_edge vs clk'event"and "numeric_std vs std_logic_arith"

This makes me think you try and fight the language rather than work with it.

VHDL-2008 makes numeric_unsigned a standard. So it may be the language is fighting to work with me.

However, I still prefer my method of selecting only the specific operators. This allows me to have a distinction between signed, unsigned, and ordered values. eg, where "+" is a convenient way to get the next item in sequence, but does not impose an actual numerical value.