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