<Forty-Bot>
I've tried playing around with adding different numbers, but I can't seem to find a result which ends up with the same result
kraiskil has joined #yosys
<Lofty>
Forty-Bot: generally Yosys will not infer carry logic for anything other than addition/subtraction
<Forty-Bot>
right; I had previously seen a carry chain inferred by constructing two numbers, adding them together, and then choosing the appropriate bits from the result
<Forty-Bot>
so I was wondering if there was a general technique related to that
<Lofty>
Sometimes you just have to tell the compiler what you want
<Forty-Bot>
funnily enough, nextpnr reports completely wrong timing with the code I posted
<Forty-Bot>
it doesn't consider the carry chain at all
Asuu has joined #yosys
kraiskil has quit [Ping timeout: 265 seconds]
Asu has quit [Ping timeout: 260 seconds]
kraiskil has joined #yosys
<Lofty>
Forty-Bot: that's probably a hint something got messed up, and I suspect it's the LUT inputs
<Lofty>
daveshah, what do you think?
<Forty-Bot>
I don't know; I tested it with icetime and it correctly identified the chain as the critical path
<Forty-Bot>
I also tested some other verilog files, and I found that nextpnr consistently overestimates when compared to icetime
<Forty-Bot>
but I didn't find another case where they completely disagreed
<Lofty>
Forty-Bot: it's never a bad thing to overestimate delay
Forty-Bot has left #yosys [#yosys]
Forty-Bot has joined #yosys
<Forty-Bot>
yeah but they shouldn't disagree by 50 Mhz on a 16-bit adder
<Forty-Bot>
e.g. nextpnr gives 227.79 MHz (which is similar to the 220 MHz that Lattice has in their datasheet) and icetime gives 156.11 MHz
<daveshah>
I have a feeling this is because icetime incorrectly counts constant-driving LUTs as part of timing paths
<daveshah>
And it also counts IO ports as part of the Fmax, whereas nextpnr only looks at interior paths and does IO as a separate "async" domain (to be improved soon)