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

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

[bugzilla-daemon]

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

            Bug ID: 326
           Summary: nmutil.clz to be retired (removed) because it is
                    identical to PriorityEncoder
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: PC
                OS: Mac OS
            Status: CONFIRMED
          Severity: enhancement
          Priority: ---
         Component: Source Code
          Assignee: lkcl@lkcl.net
          Reporter: lkcl@lkcl.net
                CC: libre-riscv-dev@lists.libre-riscv.org
   NLnet milestone: ---

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

-- 
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

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

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.libre-soc.org/
                   |                            |show_bug.cgi?id=312

-- 
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

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

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|lkcl@lkcl.net               |mtnolan2640@gmail.com

-- 
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

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

[bugzilla-daemon]

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

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

[bugzilla-daemon]

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

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

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

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl@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.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev