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

[bugzilla-daemon@libre-soc.org]

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

--- Comment #1 from Michael Nolan <mtnolan2640@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:

clz.py:
   Cells: 211
   Longest Topological Path: 10

PriorityEncoder:
   Cells: 435
   Longest Topological Path: 63

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev