determining of the position of the MSB

J

Johan Bernspĺng

Guest
I have a signal of an arbitrary width (say 16, but not necessarily a
width that is a power of two) which is unsigned. I want to determine the
position of the most significant (set) bit, i.e. the position of the
highest '1'.

The brute force method for this would be something like this, but I
doubt it is the most efficient method. Any ideas what would improve the
design in terms of device utilization?

bitwidth_calc : process(clk) is
begin
if rising_edge(clk) then
if new_data = '1' then
for i in current_data'range loop
if current_data(current_data'high - i) = '1' then
bit_width <= (current_data'length - i);
end if;
end loop;
else
bit_width <= (others => '0');
end if;
end if;
end process;

regards
johan

--
-----------------------------------------------
Please remove the x's in the email address if
replying to me personally.

Johan Bernspĺng, xjohbex@xfoix.se
 
On Tue, 27 Jul 2004 14:20:32 +0200, Johan Bernspĺng <xjohbex@xfoix.se>
wrote:

I have a signal of an arbitrary width (say 16, but not necessarily a
width that is a power of two) which is unsigned. I want to determine the
position of the most significant (set) bit, i.e. the position of the
highest '1'.
Click to expand...
There's a recursive solution to this, which works fairly well
for modest widths. The following description makes good sense
if the number of bits is a power of 2; if not, you'll need to
pad the width to an exact power of 2 with leading zeros.
Synthesis tools would get rid of lots of unwanted logic
in this case, because so many inputs are known to be zero.

function top_bit_position(bunch_of_bits):
if (N = 2)
result := (upper bit of the two bits)
elsif (any bit in the upper half is set)
result := '1' & top_bit_position(upper_half_of_bunch_of_bits)
else
result := '0' & top_bit_position(lower_half_of_bunch_of_bits)

This synthesises to piles of wide OR functions and a few
multiplexers. Its speed is likely to be dominated by the
speed of wide OR functions in your chosen technology -
the multiplexers are small and simple.

I'll post the code if anyone's interested.

There *should* be some nice elegant solution based on using
FPGA ripple carry chains, but I've not yet worked out how
to do that. Any experts on Brand A / Brand X please speak up.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

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

I'll post the code if anyone's interested.
I'm very interested, indeed. I think your solution looks interesting,
Click to expand...
it's going to be interesting to see if it requires less space on the
device than my brute force method or not.

There *should* be some nice elegant solution based on using
FPGA ripple carry chains, but I've not yet worked out how
to do that. Any experts on Brand A / Brand X please speak up.
There always seem to be a more elegant solution, doesn't it?
Click to expand...


JaI, I couldn't find the specific code page you mentioned. I'd be happy
if you could send me the link when you have some time to spare.

/Johan

--
-----------------------------------------------
Please remove the x's in the email address if
replying to me personally.

Johan Bernspĺng, xjohbex@xfoix.se
 
On Tue, 27 Jul 2004 17:08:04 +0200, Johan
Bernspĺng <xjohbex@xfoix.se> wrote:

Jonathan Bromley wrote:
[recursive solution to find-the-topmost-1-bit]
Click to expand...

I'll post the code if anyone's interested.
I'm very interested, indeed. I think your solution looks interesting,
it's going to be interesting to see if it requires less space on the
device than my brute force method or not.
Click to expand...
Targeting Spartan-2 and using a well-known FPGA synthesis tool,
the LUT count is as follows:

number of number of
input bits LUTs
4 2
8 6
16 16
32 35
64 78
128 167

so you can see that, for reasonable-size input, the area
is remarkably close to proportional to the number of inputs.
Dunno how that compares with yours.

Absolutely no promises that this code is 100% correct,
and no promises that it compiles with all possible tools -
for example, Synopsys DC chokes on the "while" loop in
function bits_to_fit, even though that function is used
only to compute constants.

All the important work happens in function "topbit".
At the end there's a very simple example of how you
might use that function in a design.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
library ieee;
use ieee.std_logic_1164.all;

package topbit_pkg is
function topbit (p : std_logic_vector) return std_logic_vector;
end;


package body topbit_pkg is

--------------------------- Internal functions ---

-- bits_to_fit:
-- one of many possible ways to compute the number of bits
-- required to represent N as an unsigned integer
--
function bits_to_fit(n: positive) return natural is
variable nn: natural;
variable bits: natural;
begin
nn := n;
bits := 0;
while nn > 0 loop
bits := bits+1;
nn := nn/2;
end loop;
return bits;
end;

-- or_all:
-- given a std_logic_vector, OR all its bits together
-- and return the single-bit result
--
function or_all(p: std_logic_vector) return std_logic is
variable r: std_logic;
begin
r := '0';
for i in p'range loop
r := r or p(i);
end loop;
return r;
end;

------------------------------- Public functions ---

-- topbit:
-- return the bit number of the most significant bit that is
-- set in a std_logic_vector. Note that the bits are ALWAYS
-- numbered so that the LSB is bit 0 and the MSB is bit n-1,
-- regardless of the bit numbering scheme in your original vector.
-- Note also that this function will return the result 0 in two
-- different cases: when the LSB only is set, and when no bits
-- at all are set. To disambiguate these two cases, you need to
-- concatenate one extra bit on the LSB end of the input vector.
--
function topbit (p : std_logic_vector) return std_logic_vector is

-- Number of bits required to represent the result
constant wN: positive := bits_to_fit(p'length-1);

-- Number of input bits, rounded up to an exact power of 2
constant wP: positive := 2**wN;

-- Input vector, widened to have wP bits, bit numbers normalised
variable pv: std_logic_vector(wP-1 downto 0);

-- Temporary variable for the result
variable n: std_logic_vector(wN downto 1);

begin

if p'length <= 2 then

-- Degenerate case of only 2 input bits: easy
n(n'right) := p(p'left);

else -- p'length > 2, we must divide it into pieces

-- Make a normalised version of the input
pv := (others => '0');
pv(p'length-1 downto 0) := p;

-- If any bits at all are set in the top half...
if or_all(pv(wP-1 downto wP/2)) = '1' then

-- MSB of result is '1', LSBs determined by upper half
n := '1' & topbit(pv(wP-1 downto wP/2));

else -- no bits in the top half are set

-- MSB of result is '0', LSBs determined by lower half
n := '0' & topbit(pv(wP/2-1 downto 0));

end if;

end if;

return n;

end;

end;


-------------------- Example entity that uses the function
library ieee;
use ieee.std_logic_1164.all;
use work.topbit_pkg.all;

entity nbits_e is
port (
p: in std_logic_vector(31 downto 0);
q: out std_logic_vector(4 downto 0)
);
end;

architecture a of nbits_e is
begin
q <= topbit(p);
end;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hope this helps
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Tue, 27 Jul 2004 14:20:32 +0200, Johan Bernspĺng
<xjohbex@xfoix.se> wrote:

I have a signal of an arbitrary width (say 16, but not necessarily a
width that is a power of two) which is unsigned. I want to determine the
position of the most significant (set) bit, i.e. the position of the
highest '1'.
Click to expand...
Just a thought: There's a cutesy-tricksy method based on the fact
that the logical AND of any binary number with its twos complement
gives you a one-hot value with the "hot" bit at the position of
the LEAST significant 1 bit of the original vector. For example:

original value 101100100
2s complement 010011100
(logical AND) &&&&&&&&&
000000100

This value can then be fed into your favourite onehot-to-binary
converter circuit (just a large bunch of OR gates) to get the
required bit number.

To solve your original problem - find the MOST significant bit -
you need to reverse the original bit-pattern before doing this.

This method is appealing because it automatically exploits
the FPGA's fast carry chain to generate the 2s complement
value (arithmetic negative). So it should be fast.

However, when I tried it just now, on a 32-bit vector,
it came out about twice as large as, and 30% slower than,
the recursive solution I've posted. :-(

It's still a pretty little property of binary numbers, though.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

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

Jonathan Bromley wrote:
On Tue, 27 Jul 2004 14:20:32 +0200, Johan Bernspĺng
xjohbex@xfoix.se> wrote:


I have a signal of an arbitrary width (say 16, but not necessarily a
width that is a power of two) which is unsigned. I want to determine the
position of the most significant (set) bit, i.e. the position of the
highest '1'.


Just a thought: There's a cutesy-tricksy method based on the fact
that the logical AND of any binary number with its twos complement
gives you a one-hot value with the "hot" bit at the position of
the LEAST significant 1 bit of the original vector. For example:

original value 101100100
2s complement 010011100
(logical AND) &&&&&&&&&
000000100

This value can then be fed into your favourite onehot-to-binary
converter circuit (just a large bunch of OR gates) to get the
required bit number.

To solve your original problem - find the MOST significant bit -
you need to reverse the original bit-pattern before doing this.

To Johan,
Click to expand...
If I well remember the solution take by f-cpu project is based on this
approach

snip
Click to expand...
JaI
 
Hi,

Johan Bernspĺng wrote:

Jonathan Bromley wrote:

snip
JaI, I couldn't find the specific code page you mentioned. I'd be happy
if you could send me the link when you have some time to spare.

/Johan
Click to expand...
The web site address is www.f-cpu.org

The vhdl source is in the directory new, but inside a snapshot archive.

I don't remember exactly in which one, and unfortunately I haven't time
to browse all of them to find who have made it.

Try to see in mailing list archive http://archives.seul.org/f-cpu/f-cpu/
Unfortunately this archive haven't search engine, but I think that you
can found a comment into 2002 archives.

Or keep solution by Johnatan Bromley.

JaI
 
Hi Jonathan,
You can implement the wide OR gates with the carry logic. Each four bit
chunk of the OR gate is a 4 input NOR made in the CLB 4-LUT which feeds the
select input of the MUXCY. The Ci input of the MUXCY comes from the previous
four bit chunk, Lo goes to the next chunk. The Di input of the MUXCY is
driven to '1'. If you do it this way, the total number of LUTs ~=
0.25*number of bits in the OR gate.
Cheers, Syms.
p.s. See MUXCY_L in the Xilinx libraries guide

"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:9nocg0933dhad1mjqh62rufpvgtodceuk2@4ax.com...
There *should* be some nice elegant solution based on using
FPGA ripple carry chains, but I've not yet worked out how
to do that. Any experts on Brand A / Brand X please speak up.
Click to expand...
 
On Tue, 27 Jul 2004 19:37:07 +0200, Johan Bernspĺng <xjohbex@xfoix.se>
wrote:

My code is attached if anyone's interested to look at it..
Click to expand...
and it contains the highly suggestive process name

read_adc_proc:

Is this a hint? Are you capturing the comparator outputs
in a flash A/D converter? If so, your find-first-bit
problem is MUCH simpler, because the flash A/D comparator
outputs form a thermometer code: if a given bit is set
then you know in advance that all lower bits are set.
My solution still works, but the or_all() function is
unnecessary; you need only look at the lowest bit of
the value, instead of the OR of all its bits. This
will give a much smaller and faster solution.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Wed, 28 Jul 2004 09:10:37 +0100, Jonathan Bromley
<jonathan.bromley@doulos.com> wrote:

On Tue, 27 Jul 2004 12:03:28 -0700, "Symon" <symon_brewer@hotmail.com
wrote:

Hi Jonathan,
You can implement the wide OR gates with the carry logic.

Yeah. Various other stuff can be done in the MUXCYs too;
for example, converting the collection of bits into a
thermometer code, which is very easy to re-code as binary.

However, as I'm not a Xilinx synthesis guru I don't know how
to persuade synthesis tools to do this (if it's possible at
all). Any ideas? (I'd ask our Xilinx experts here in the
office, but they're all away doing other stuff right now!)
Click to expand...
Easy: just instantiate the relevant Xilinx unisim primitives in the
HDL source. It's portable over all synthesisers (except those that
think they understand the primitives and try to "optimise" them - I've
had problems with various versions of Synplify) and also simulates
correctly (if slowly).

Regards,
Allan.
 
That's how I do it, by instantiation. As you say Allan, the major problem
with this kinda stuff is the tool trying to be clever. FCS, if I've gone to
the trouble of instantiating primitives, isn't it obvious I know what I
want? Bloody software engineers. ;-)
Cheers, Syms.
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:isoeg05ehc5ekr2vog5sdfbeftlro1c0bd@4ax.com...
On Wed, 28 Jul 2004 09:10:37 +0100, Jonathan Bromley
jonathan.bromley@doulos.com> wrote:


Easy: just instantiate the relevant Xilinx unisim primitives in the
HDL source. It's portable over all synthesisers (except those that
think they understand the primitives and try to "optimise" them - I've
had problems with various versions of Synplify) and also simulates
correctly (if slowly).

Regards,
Allan.
Click to expand...
 
OK, I'll bite! Do you mean the 'fat tree' method? Convert the thermometer
code to one hot, then use a tree of OR gates to get binary code?
Cheers, Syms.
"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:5ineg0tk3h9rrvge0emarcn61nr5rf52mj@4ax.com...
for example, converting the collection of bits into a
thermometer code, which is very easy to re-code as binary.
Click to expand...
 
On Thu, 29 Jul 2004 10:42:38 -0700, "Symon" <symon_brewer@hotmail.com>
wrote:

OK, I'll bite! Do you mean the 'fat tree' method? Convert the thermometer
code to one hot, then use a tree of OR gates to get binary code?
Cheers, Syms.
"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:5ineg0tk3h9rrvge0emarcn61nr5rf52mj@4ax.com...
for example, converting the collection of bits into a
thermometer code, which is very easy to re-code as binary.
Click to expand...
That works, for sure. But I think ther'es an easier way
(though I haven't done systematic investigations about the
speed or size implications). What I had in mind was a tree
of 2-to-1 multiplexers.

Suppose we have a thermometer code of N bits, such that 2**B = M.
And suppose those bits are numbered from 0 to N-1, so for any
given encoded value X, bits 0..X inclusive are set and bits
X+1..N-1 are zero. We need an unsigned integer with B bits to
represent the encoded value; let's label those bits B-1 downto 0
in the conventional way.

To VHDL-ise these objects:
constant B: positive := ...;
variable thm_code: std_logic_vector(0 to 2**B-1); -- thermo code
variable bin_code: std_logic_vector(B-1 downto 0); -- binary value

The topmost bit of the result is precisely the value of
thm_code(2**(B-1)), 'coz that bit will be set if and only if
we're encoding a value >= 2**(B-1).

The remaining bits of the result are
EITHER
the thermometer code represented by thm_code(2**(B-1) to 2**B-1)
(the upper half of thm_code) if bit 2**(B-1) is set
OR
the thermometer code represented by thm_code(0 to 2**(B-1)-1)
(the lower half of thm_code) if bit 2**(B-1) is clear

And so on until you run out of code bits. My delight in recursive
solutions is showing itself again :)

function thermo_decoder ( thm_code: std_logic_vector )
return std_logic_vector is
variable s: std_logic_vector(0 to 0);
constant N: positive := thm_code'length;
constant mid: natural := N / 2;
begin
-- protect against goofs
assert thm_code'ascending and thm_code'left = 0;
assert N >= 2;
assert [N is an exact power of 2];
-- pick the bit of interest
s(0) := thm_code(mid);
if thm_code'length = 2 then
return s;
elsif s(0) = '1' then
return s & thermo_decoder(thm_code(mid to N-1));
else
return s & thermo_decoder(thm_code(0 to mid-1));
end if;
end;

Stopping the recursion at length=2 spares us the need to
use null ranges, which are a nice feature of VHDL but
poorly supported by synthesis tools.

A very quick-and-dirty attempt at synthesis for this, with
256-bit thermometer code and 8-bit output and targeting
Spartan-2, gave:
LUTs delay
mux tree 199 10ns
"fat tree" 367 15ns

I would guess that your OR-gate version could easily
be made much faster by constructing the OR gates
from chains of MUXCYs, but I don't know for sure.

Any other ideas?
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

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

Jonathan Bromley wrote:
[...]
The topmost bit of the result is precisely the value of
thm_code(2**(B-1)), 'coz that bit will be set if and only if
we're encoding a value >= 2**(B-1).

The remaining bits of the result are
EITHER
the thermometer code represented by thm_code(2**(B-1) to 2**B-1)
(the upper half of thm_code) if bit 2**(B-1) is set
OR
the thermometer code represented by thm_code(0 to 2**(B-1)-1)
(the lower half of thm_code) if bit 2**(B-1) is clear

And so on until you run out of code bits. My delight in recursive
solutions is showing itself again :)
Click to expand...
That's a nice solution, but probably the second best one. The problem is
that you'll have to get the thermometer code first. But you can also
process the original operand directly:

function findmsb (X : in std_ulogic_vector) return std_ulogic_vector is
constant N : natural := X'length; -- assume it's a power of two
constant xx : std_ulogic_vector(N-1 downto 0);
begin
xx := to_X01(X); -- convert to something more useful
if N = 2 then
return xx(1 downto 1);
elsif xx(N-1 downto N/2) = (N-1 downto N/2 => '0') then
-- lower half
return '0' & findmsb(xx(N/2-1 downto 0));
else
-- upper half
return '1' & findmsb(xx(N-1 downto N/2));
end if;
end findmsb;

This should result in a MUX tree interleaved with an OR tree. The only
drawback is that a zero operand and an operand with only the LSB set
will have the same result (others => '0'). But you can change that by
adding another MUX at the output:

function findmsb2 (X : in std_ulogic_vector) return std_ulogic_vector is
constant N : natural := X'length; -- assume it's a power of two
constant xx : std_ulogic_vector(N-1 downto 0);
begin
xx := to_X01(X); -- convert to something more useful
if xx(N-1) = '1' then
-- Note: findmsb will always return a zero vector here.
-- But it's easier to call findmsb than to calculate
-- the required number of bits :)
return '1' & findmsb(std_ulogic_vector'(N-1 downto 0 => '0'));
else
return '0' & findmsb(xx(N-2 downto 0) & '1');
end if;
end findmsb2;

Now a zero operand produces a zero result, while all other inputs result
in the index number of the MSB, counted from N downto 1 (left to right,
as usual).

Note: The code is provided without any warranty. Use at your own risk.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
 
Hi Guys,
I'll try and think about this more over the weekend, in between time I found
this paper about the 'fat tree' decoder.
http://www.cse.psu.edu/~chip/final_mwscas02.pdf
Bits of the tree aren't needed and can be 'liposuctioned' away!

I wonder if the mux solutions work so well in terms of LUT efficiency in the
Xilinx parts because of the muxf5s in the CLBs?
Interesting stuff, cheers, Syms.

"Michael Riepe" <michael@stud.uni-hannover.de> wrote in message
news:cedtg8$6oo$1@newsserver.rrzn.uni-hannover.de...
Hi.

Jonathan Bromley wrote:
[...]
The topmost bit of the result is precisely the value of
thm_code(2**(B-1)), 'coz that bit will be set if and only if
we're encoding a value >= 2**(B-1).

The remaining bits of the result are
EITHER
the thermometer code represented by thm_code(2**(B-1) to 2**B-1)
(the upper half of thm_code) if bit 2**(B-1) is set
OR
the thermometer code represented by thm_code(0 to 2**(B-1)-1)
(the lower half of thm_code) if bit 2**(B-1) is clear

And so on until you run out of code bits. My delight in recursive
solutions is showing itself again :)

That's a nice solution, but probably the second best one. The problem is
that you'll have to get the thermometer code first. But you can also
process the original operand directly:

function findmsb (X : in std_ulogic_vector) return std_ulogic_vector is
constant N : natural := X'length; -- assume it's a power of two
constant xx : std_ulogic_vector(N-1 downto 0);
begin
xx := to_X01(X); -- convert to something more useful
if N = 2 then
return xx(1 downto 1);
elsif xx(N-1 downto N/2) = (N-1 downto N/2 => '0') then
-- lower half
return '0' & findmsb(xx(N/2-1 downto 0));
else
-- upper half
return '1' & findmsb(xx(N-1 downto N/2));
end if;
end findmsb;

This should result in a MUX tree interleaved with an OR tree. The only
drawback is that a zero operand and an operand with only the LSB set
will have the same result (others => '0'). But you can change that by
adding another MUX at the output:

function findmsb2 (X : in std_ulogic_vector) return std_ulogic_vector is
constant N : natural := X'length; -- assume it's a power of two
constant xx : std_ulogic_vector(N-1 downto 0);
begin
xx := to_X01(X); -- convert to something more useful
if xx(N-1) = '1' then
-- Note: findmsb will always return a zero vector here.
-- But it's easier to call findmsb than to calculate
-- the required number of bits :)
return '1' & findmsb(std_ulogic_vector'(N-1 downto 0 => '0'));
else
return '0' & findmsb(xx(N-2 downto 0) & '1');
end if;
end findmsb2;

Now a zero operand produces a zero result, while all other inputs result
in the index number of the MSB, counted from N downto 1 (left to right,
as usual).

Note: The code is provided without any warranty. Use at your own risk.

--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de
"All I wanna do is have a little fun before I die"
Click to expand...
 
On Fri, 30 Jul 2004 15:23:40 +0200, Michael Riepe
<michael@stud.uni-hannover.de> wrote:

Hi.

Jonathan Bromley wrote:
[...]
My delight in recursive
solutions is showing itself again :)

That's a nice solution, but probably the second best one. The problem is
that you'll have to get the thermometer code first. But you can also
process the original operand directly:

function findmsb (X : in std_ulogic_vector) return std_ulogic_vector is
constant N : natural := X'length; -- assume it's a power of two
constant xx : std_ulogic_vector(N-1 downto 0);
begin
xx := to_X01(X); -- convert to something more useful
if N = 2 then
return xx(1 downto 1);
elsif xx(N-1 downto N/2) = (N-1 downto N/2 => '0') then
Click to expand...
I already posted essentially this solution in response to the
original poster on this thread. I agree that it's nice.
However, in Xilinx and Altera FPGAs I suspect that it may be
less attractive than the thermometer code version, because
you can very easily construct a thermometer code using the
carry chain (if you're prepared to instantiate the MUXCYs
by hand, as others have noted).

The only
drawback is that a zero operand and an operand with only the LSB set
will have the same result (others => '0'). But you can change that by
adding another MUX at the output:
Click to expand...
Or by concatenating an extra redundant bit whose value is 1.

Fun stuff.

--
Jonathan Bromley

Jonathan Bromley
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top