VHDL question

  signal next                : integer range -1 to 2;

  function find_first(vector, enable : std_ulogic_vector(0 to 2))
    return integer is
    variable result : integer;
  begin
    result := -1;
     -- omitted calc of first in range of 0..2
    return result;
  end find_first;

  next <= find_first(valid, enable);

-------
is this code fully synthesis safe?
how many bits is variable next?

this is not my code, i need to troubleshoot it,
i guess it is 100% legal code, just curious how are
synthesis tools doing it

next could be 2 bits, but then -1 would map to 0 ?
or ?

Antti

Antti <antti.lukats@googlemail.com> wrote:
<  signal next                : integer range -1 to 2;
 
<  function find_first(vector, enable : std_ulogic_vector(0 to 2))
<    return integer is
<    variable result : integer;
<  begin
<    result := -1;
<     -- omitted calc of first in range of 0..2
<    return result;
<  end find_first;
 
<  next <= find_first(valid, enable);
 
< is this code fully synthesis safe?
< how many bits is variable next?

I have done priority encoders in verilog before, though
always specifying the width of the result.
 
< this is not my code, i need to troubleshoot it,
< i guess it is 100% legal code, just curious how are
< synthesis tools doing it

I believe it is fine.  In verilog, the result would be 32 bits
(on the usual implementation).  If you assign the result to a
something smaller, it will truncate.  Also, the tools are pretty
good at removing unused logic.  Still, I don't see any reason
not to specify the size of the result.
 
< next could be 2 bits, but then -1 would map to 0 ?
< or ?

3  (the low two bits of twos complement -1)

-- glen

On Sep 22, 2:53=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Antti <antti.luk...@googlemail.com> wrote:
>
> < =A0signal next =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: integer range -1 to 2;
>
> < =A0function find_first(vector, enable : std_ulogic_vector(0 to 2))
> < =A0 =A0return integer is
> < =A0 =A0variable result : integer;
> < =A0begin
> < =A0 =A0result :=3D -1;
> < =A0 =A0 -- omitted calc of first in range of 0..2
> < =A0 =A0return result;
> < =A0end find_first;
>
> < =A0next <=3D find_first(valid, enable);
>
> < is this code fully synthesis safe?
> < how many bits is variable next?
>
> I have done priority encoders in verilog before, though
> always specifying the width of the result.
>
> < this is not my code, i need to troubleshoot it,
> < i guess it is 100% legal code, just curious how are
> < synthesis tools doing it
>
> I believe it is fine. =A0In verilog, the result would be 32 bits
> (on the usual implementation). =A0If you assign the result to a
> something smaller, it will truncate. =A0Also, the tools are pretty
> good at removing unused logic. =A0Still, I don't see any reason
> not to specify the size of the result.
>
> < next could be 2 bits, but then -1 would map to 0 ?
> < or ?
>
> 3 =A0(the low two bits of twos complement -1)
>
> -- glen

yeah i assumed 3
but it could be 2  if doing hand coded functionally same code

Antti

On Sep 22, 7:18=A0am, Antti <antti.luk...@googlemail.com> wrote:
> =A0 signal next =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: integer range -1 to 2;
>
> =A0 function find_first(vector, enable : std_ulogic_vector(0 to 2))
> =A0 =A0 return integer is
> =A0 =A0 variable result : integer;
> =A0 begin
> =A0 =A0 result :=3D -1;
> =A0 =A0 =A0-- omitted calc of first in range of 0..2
> =A0 =A0 return result;
> =A0 end find_first;
>
> =A0 next <=3D find_first(valid, enable);
>
> -------
> is this code fully synthesis safe?

It looks to be.

> how many bits is variable next?
>

To know that you would need to look at the declaration for 'next' not
the function that assigns to 'next'.  The defined range for the
integer will end up defining the number of bits required for
synthesis.  Whether it can be implemented in less bits would depend on
whether or not the logic reduces to something smaller.  For example,
the code you listed 'as is' would reduce to a constant and therefore
most likely result in 0 bits for 'next'.

signal next: integer; -- 32 bits
signal next: integer range 0 to 7; -- 3 bits
signal next: integer range -3 to 3; -- 3 bits
signal next: integer range -4 to 3; -- 3 bits also

>
> next could be 2 bits, but then -1 would map to 0 ?
> or ?

-1 in two bits is "11"

Kevin Jennings

On Sep 22, 7:18=A0am, Antti <antti.luk...@googlemail.com> wrote:
> =A0 signal next =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: integer range -1 to 2;
>

I missed this line in my first post.  So for starters, 'next' would
have to be 3 bits based on the defined range.  As I mentioned in the
previous post, depending on what the logic actually is, some of the
bits could be optomized away during synthesis.  If there is a two bit
(or one bit) implementation, synthesis tools will most likely find
it.  Reduction of simple boolean logic as in this case is their strong
suit.

Kevin Jennings

On Sep 22, 7:27=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
> On Sep 22, 7:18=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > =A0 signal next =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: integer range -1 to 2;
>
> I missed this line in my first post. =A0So for starters, 'next' would
> have to be 3 bits based on the defined range. =A0As I mentioned in the
> previous post, depending on what the logic actually is, some of the
> bits could be optomized away during synthesis. =A0If there is a two bit
> (or one bit) implementation, synthesis tools will most likely find
> it. =A0Reduction of simple boolean logic as in this case is their strong
> suit.
>
> Kevin Jennings

Most synthesis tools implement symmetrical signed ranges, so -1 to 2
takes the same number of bits as required for -3 to 2, which is 3
bits.

Most synthesis tools will implement "integer range 6 to 7" as three
bits too (same as for 0 to 7).

Most synthesis tools will not alter the coding to use fewer bits.

Synthesis might be able to optimize decoding the value based on the
range specification (i.e. values -2 and -3, while representable in
three bits, are not, by definition, possible), such that decoding,
e.g. 2, only requires looking at two of the bits, etc.

Andy

On Sep 22, 7:34=A0pm, Andy <jonesa...@comcast.net> wrote:
> On Sep 22, 7:27=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
>
> Most synthesis tools will implement "integer range 6 to 7" as three
> bits too (same as for 0 to 7).
>
> Most synthesis tools will not alter the coding to use fewer bits.
>

That's only one of the first steps in the synthesis process though.
Synthesis tools will then look at the boolean logic that gets created
and optomize that.  As I mentioned previously, the OP's example where
the only assignment was to a value of -1 (because he intentionally
commented out the rest for clarity) would cause 'next' to get reduced
to a constant which would then get absorbed into whatever logic that
depends on 'next' so 'next' would be implemented in 0 bits.

Another example would be if the only use of some integer that is
defined to be in the range of 0 to 7 is of the form "if my_integer >=3D
4 then..." would result in only one bit being implemented...this would
also be true if the range was define to be 4 to 7 or -529 to 683.

The bottom line is one can't really answer the question of how many
bits it will take to implement some integer without knowing the
context of how that integer gets used (i.e. what is the logic that
uses that integer).  Knowing the defined range for the integer tells
you the upper bound on how many bits it might take, not the actual
number.

Kevin Jennings

On Sep 22, 8:27=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
Disregard this part..
> this would if the range was ... or -529 to 683.
>

I see what you are getting at, and you are correct, to a point. Yes,
if it turns out that none of the bits is ever used, then none of the
bits will get implemented (we have no idea where/if "next" gets used).

However if it is used, the coding, or those bits that are left of it,
in all the synthesis tools I have seen, will be from the original
three bit encoding. For example, I have yet to see a synthesis tool
that would recode range -1 to 2 as range 0 to 3, which would allow ALL
valid values to be encoded with only two bits.

> Another example would be if the only use of some integer that is
> defined to be in the range of 0 to 7 is of the form "if my_integer >=
> 4 then..." would result in only one bit being implemented...this would
> also be true if the range was define to be 4 to 7 ...

Actually, decoding "my_integer >= 4" from a value with a valid range
of 4 to 7 could take zero bits (constant TRUE).

Synthesis sometimes (I haven't nailed down exactly under what
conditions) looks at what gets stored in an object as well as what is
read from it to make optimizations. I have seen this occur with a
counter that counted from 0 to 5 and rolled over, unconditionally. It
happened to be a natural range 0 to 5. I don't know whether Symplify
took the range as a hint, or performed a reachability analysis on the
counter, but it only looked at two of the bits to decode some of the
values.

Andy

On Sep 23, 9:07=A0am, Andy <jonesa...@comcast.net> wrote:
> I see what you are getting at, and you are correct, to a point. Yes,
> if it turns out that none of the bits is ever used, then none of the
> bits will get implemented (we have no idea where/if "next" gets used).
>
> However if it is used, the coding, or those bits that are left of it,
> in all the synthesis tools I have seen, will be from the original
> three bit encoding. For example, I have yet to see a synthesis tool
> that would recode range -1 to 2 as range 0 to 3, which would allow ALL
> valid values to be encoded with only two bits.
>
[snip]
>
> Andy

It turns out that even with simple binary encoding, the values
-1 to 2 (or any set of four contiguous integer values) can
always be decoded using only bits 1 and 0 as these are
different for each value.  In the case of -1 to 2 they are
11 00 01 10, and so even though bit 2 also changes it is
not necessary to use bit 2 for decoding IF the optimising
agent is smart enough to detect that bit 2 can be described
as a function of bits 1 and 0 and is therefore redundant.

Regards,
Gabor