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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Tue May 19 18:05:31 BST 2020


--- Comment #1 from Michael Nolan <mtnolan2640 at gmail.com> ---
(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:

   Cells: 211
   Longest Topological Path: 10

   Cells: 435
   Longest Topological Path: 63

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

More information about the libre-riscv-dev mailing list