<twnqx>
tnt: what exactly is the issue? out of curiosity, and assuming that ctrl_bus_mode and req_valid may cause both hit and miss to be 0 or 1 due to some kind of gating
<ZirconiumX>
twnqx: lu_miss and lu_hit are identical
<ZirconiumX>
But it's using two LUTs instead of one
<twnqx>
are they?
<ZirconiumX>
Yes, they share three terms and the fourth is a constant
<ZirconiumX>
They are identical functions
rohitksingh_ has joined #yosys
<tnt>
Well their content is not identical.
<twnqx>
hm. they share three inputs and one constant, but they may produce different results
<tnt>
But the lut on the left can be merged
<twnqx>
yes, that was something i just noticed, too
<tnt>
instead of 3 luts and 2 layers, you can do the same in 2 luts and 1 layer.
<ZirconiumX>
But the lut on the left is a function of two inputs
<ZirconiumX>
3 + 2 > 4
<tnt>
Well no ... because the '3' is the output of the first lut
<twnqx>
and you have one spare input (constant zero) plus that output on each of the second luts
<twnqx>
so two -> two, i was wondering if you were referring to that part, too
<ZirconiumX>
Oh, right, now I get you
<twnqx>
(unless someone used <= in between and it has to be buffered synchronously)
<ZirconiumX>
You'd see a flop in that case
<twnqx>
ah, ok. not used to reading these :)
<daveshah>
Is it possible that one of the LUTs is actually coming from Yosys?
<daveshah>
Part of a carry or something
rohitksingh has quit [Ping timeout: 265 seconds]
<tnt>
No adders in that whole design.
<twnqx>
which reminds me of a few tests i wanted to make, e.g. if reg < 128 has the same output as |reg[upper bits]
<daveshah>
So just ABC being weird then
<twnqx>
well, !|reg[upper_bits]
<tnt>
the first lut corresponding verilog is in another module / hierarchy level ... but that should not change anything.
<twnqx>
so it calculates |way_match in the first lut? or what does it do there, looks weird as that syntax makes no sense with only one bit
<daveshah>
I suspect this is something to do with how inversions are represented in abc
<tnt>
twnqx: way_match is [3:0] and each of those signal is actual an 'OR' of 2 signals. (so it's a total of 8 signals that need to be ORed). So you get two lut4 to or each group of 4 and then those 2 signals are the input to the first lut on the diagram.
<twnqx>
ah
<tnt>
if I only have _hit or only have _miss, then it correctly merges into a single lut4.
<awygle>
i swear there's another abc alternative but i can't remember what it's called. my brain is just throwing up the word "squirrel".
<twnqx>
have you tried !|way_match instead of ~? out of curiosity
<tnt>
twnqx: doesn't change anything.
<twnqx>
then it doesn't like duplication of terms :P
vidbina has joined #yosys
HEGAZY has quit [Quit: Konversation terminated!]
<ZirconiumX>
awygle: So, mockturtle mentions using an algorithm a lot like ABC &mf
<ZirconiumX>
So I tried just using &mf
<ZirconiumX>
It's a little bit worse than the current ABC9 flow
twnqx has quit [Ping timeout: 256 seconds]
<awygle>
it has at least two approaches for lut mapping, the mf-like one and the SAT one (which is probably slow i'd guess)
<ZirconiumX>
Well, there's exactly one function called lut_mapping, so that's the only one I looked at