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

Status
Not open for further replies.
N

naught

Member level 3
Joined
Aug 25, 2012
Messages
59
Helped
4
Reputation
8
Reaction score
4
Trophy points
1,288
Location
chengdu
Visit site
Activity points
1,739
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...
 

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.
 
Re: sharing blogs about"rising_edge vs clk'event"and "numeric_std vs std_logic_arith"

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...
Click to expand...
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.
Click to expand...
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.
Click to expand...
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.
Click to expand...
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.
Click to expand...
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.
Click to expand...
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
 

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.
Click to expand...
There are several arguments against that point.

Then you're missing out on some logic optimizations
Click to expand...
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.
Click to expand...
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.
Click to expand...
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)
 

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

permute said:
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.
Click to expand...

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?
 
Last edited:

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

permute said:
There are several arguments against that point.
Click to expand...
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.
Click to expand...
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...

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

Whereas, if you coded it like this...
Code: 
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
 

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?
Click to expand...
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?
Click to expand...
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...
 

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


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

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.
Click to expand...
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.
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…