[libre-riscv-dev] [Bug 326] nmutil.clz to be retired (removed) because it is identical to PriorityEncoder

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=326

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|CONFIRMED                   |RESOLVED

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Michael Nolan from comment #1)
> (In reply to Luke Kenneth Casson Leighton from comment #0)
> > i do not know how nmutil.clz came to be written: it is functionally identical
> > in absolutely every respect to PriorityEncoder, which is a pre-existing
> > standard function in nmigen.
> > 
> > nmutil.clz therefore needs to be retired, to be replaced by PriorityEncoder.
> > we do however need a formal proof of PriorityEncoder
> 
> It was written because I needed to count the number of leading zeros when I
> was working on the cordic, and I didn't know about PriorityEncoder

:)


> With some modifications (reversing input, returning $width when PE raises
> the n/invalid bit), it is identical in behavior to clz.py. However, it is
> much less efficient for large inputs. Synthesizing a 64 bit leading zero
> count module gives me these statistics:
> 
> clz.py:
>    Cells: 211
>    Longest Topological Path: 10
> 
> PriorityEncoder:
>    Cells: 435
>    Longest Topological Path: 63

iinteresting.  that's no good.  i wonder - it's probably because
PriorityEncoder
uses a pmux.  63-long paths for a 64-bit count is *rubbish*.

yep that's pretty clear: clz stays.

-- 
You are receiving this mail because:
You are on the CC list for the bug.