| Summary: | nmutil.clz to be retired (removed) because it is identical to PriorityEncoder | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Luke Kenneth Casson Leighton <lkcl> |
| Component: | Source Code | Assignee: | Michael Nolan <mtnolan2640> |
| Status: | RESOLVED INVALID | ||
| Severity: | enhancement | CC: | libre-soc-bugs |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Mac OS | ||
| See Also: | https://bugs.libre-soc.org/show_bug.cgi?id=312 | ||
| NLnet milestone: | --- | total budget (EUR) for completion of task and all subtasks: | 0 |
| budget (EUR) for this task, excluding subtasks' budget: | 0 | parent task for budget allocation: | |
| child tasks for budget allocation: | The table of payments (in EUR) for this task; TOML format: | ||
|
Description
Luke Kenneth Casson Leighton
2020-05-19 17:33:15 BST
(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 (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. |