<cr1901>
Unfortunately, I have a few problems generalizing it beyond 6 digits (the paper I took it from goes up to 10 digits/34 bits), and don't feel like tackling those right now. So I think I'll take a break.
<cr1901>
Ya know how like some software libraries will _automatically_ switch between different "strategies" to implement an algorithm depending on the size of the input? Is there precedence for this in Amaranth? Is it even a good idea without giving the user an option to override (which I'm not sure what such an option should look like)?
<whitequark[cis]>
lib.io basically does that
<whitequark[cis]>
but I don't understand why this is needed for this particular problem
<cr1901>
Naive BCD conversion is N^2 LUT usage (purely combinational), and a pipelined alternate algorithm starts giving better LUT usage (approaches 50% fewer resources) after about 15 bits.
<whitequark[cis]>
is the area or the delay the limiting factor?
<cr1901>
It's delay; for a 10-bit delay, e.g. the 3rd bcd digit depends on 8 shift-add-3 units in series