Using logical operators on parameterized-length vectors

[tristan.denhond]

Hi all,
I have a question I've been struggling with for a while. Suppose I
have a std_logic_vector named foo, 10 bits long:
signal foo : std_logic_vector(9 downto 0);
Assume foo is interpreted as an unsigned. If I want to check whether
the value of foo exceeds, say, 256, I could do
signal gt : std_logic;
gt <= '1' when unsigned(foo) > 256 else
'0';
Since I don't want to rely on synthesis tools to recognise the
possibility of doing a simple check of the 2 MSB's instead of
instantiating subtract unit and checking the sign bit, I do this:
gt <= '1' when (foo(9) or foo(8)) = '1' else
'0';
Which means I force the "2 MSB check".
This works of course, but is becomes a problem when the length of foo
is paramaterized:
signal foo : std_logic_vector(width-1 downto 0);

What I'm looking for is an elegant way of OR'ing a parameterized
number of bits in order to perform this check.

Thanks in advance for any help.

 

[Mike Treseler]

This works of course, but is becomes a problem when the length of foo
is paramaterized:
signal foo : std_logic_vector(width-1 downto 0);

If I had evidence of a synthesis tool missing
such a minimization, I would report it as a bug.
Check the RTL viewer to see if this is even a problem.
Next time the limit of 256 might change.

What I'm looking for is an elegant way of OR'ing a parameterized
number of bits in order to perform this check.

I use functions for this sort of thing.
See the function "power2" here
http://home.comcast.net/~mike_treseler/min_vec_len.vhd
for a related example.

-- Mike Treseler

 

[Andy]

If I had evidence of a synthesis tool missing
such a minimization, I would report it as a bug.
Check the RTL viewer to see if this is even a problem.
Next time the limit of 256 might change.


I use functions for this sort of thing.
See the function "power2" here
http://home.comcast.net/~mike_treseler/min_vec_len.vhd
for a related example.

-- Mike Treseler

In Synplicity, it may not show such an optimization until the
technology view, instead of the rtl view. I don't know if quartus has
the same levels of "schematic" views. Either way, I agree: optimizing
a subtraction by a constant with lsb's set to zero should be
automatic.

Andy

 

[yves.770905]

Hi all,
I have a question I've been struggling with for a while. Suppose I
have a std_logic_vector named foo, 10 bits long:
signal foo : std_logic_vector(9 downto 0);
Assume foo is interpreted as an unsigned. If I want to check whether
the value of foo exceeds, say, 256, I could do
signal gt : std_logic;
gt <= '1' when unsigned(foo) > 256 else
'0';
Since I don't want to rely on synthesis tools to recognise the
possibility of doing a simple check of the 2 MSB's instead of
instantiating subtract unit and checking the sign bit, I do this:
gt <= '1' when (foo(9) or foo(8)) = '1' else
'0';
Which means I force the "2 MSB check".
This works of course, but is becomes a problem when the length of foo
is paramaterized:
signal foo : std_logic_vector(width-1 downto 0);

What I'm looking for is an elegant way of OR'ing a parameterized
number of bits in order to perform this check.

Thanks in advance for any help.

you can define a function like this:

function or_reduce(vec: in std_logic_vector) return std_logic is
begin
for i in vec'range loop
if vec(i) = '1' then
return '1';
end if;
end for;
return '0';
end function or_reduce;

next you can call this functions as:

or_reduce(foo(foo'high downto foo'high-1));

Kind regards,

Yves

 

[Andy]

In Synplicity, it may not show such an optimization until the
technology view, instead of the rtl view. I don't know if quartus has
the same levels of "schematic" views. Either way, I agree: optimizing
a subtraction by a constant with lsb's set to zero should be
automatic.

Andy

I should expand a bit on this subject...

Until and unless the synthesis tool gives you an unacceptable result
(fails to optimize the circuit sufficiently) I would strive to
describe the operation in the most straight forward manner from a
functional point of view, not necessarily an implementation point of
view. Therefore, if the goal is to determine whether a signal is less
than 256, code it as such. Subsequent reviewers (including yourself
after a few weeks/months/beers) will more easily grasp what is going
on if the code is written in as straight-forward a manner as possible.
Trying to eek out the last nth of performance by obscuring the
functionality is not a trade I like to make unless absolutely
necessary.

Andy

 

[Mike Treseler]

Until and unless the synthesis tool gives you an unacceptable result
(fails to optimize the circuit sufficiently) I would strive to
describe the operation in the most straight forward manner from a
functional point of view, not necessarily an implementation point of
view. Therefore, if the goal is to determine whether a signal is less
than 256, code it as such. Subsequent reviewers (including yourself
after a few weeks/months/beers) will more easily grasp what is going
on if the code is written in as straight-forward a manner as possible.
Trying to eek out the last nth of performance by obscuring the
functionality is not a trade I like to make unless absolutely
necessary.

.... yes, and it hasn't been necessary for me
since I last packed a controller into a 22V10 using ABEL.

I don't know what Tristan's constraints are,
but I work on products of moderate volumes
where engineering time is the main resource
to be optimized. If my module fits, sims OK,
and makes Fmax, I'm done.

Clarity of the source code is more important
to me than converting a wasted LUT
into an unused LUT.

Having said that, I am almost always impressed
when I do look at the synthesis output.

-- Mike Treseler

 

[Jonathan Bromley]

What I'm looking for is an elegant way of OR'ing a parameterized
number of bits in order to perform this check.

You've had various excellent responses already; here's another
possibility:

unsigned(foo(foo'left downto 8)) /= 0

But in general I completely agree with Mike and Andy: if your
problem is an arithmetic one, but it happens to have a simple
bit-wise optimisation, then your best plan by far is to code
it as an arithmetic problem and leave the synthesis tool to
find the optimisation. Compilers have been doing this for
decades: for example, multiplication by a numeric value that
has only a small number of 1 bits in it can be re-written
as a series of shifts and adds, which may be much faster
on some architectures.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

You've had various excellent responses already; here's another
possibility:

unsigned(foo(foo'left downto 8)) /= 0

Very clever.
Why write a FOR loop if I don't have to?
But do save a pearl or two for your next seminar

But in general I completely agree with Mike and Andy: if your
problem is an arithmetic one, but it happens to have a simple
bit-wise optimisation, then your best plan by far is to code
it as an arithmetic problem and leave the synthesis tool to
find the optimisation. Compilers^have been doing this for

^
and university students
--mt