m_hackerfoo has quit [Remote host closed the connection]
hackerfoo has quit [Remote host closed the connection]
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #yosys
oldtopman has joined #yosys
BinaryLust has quit [Ping timeout: 272 seconds]
dys has quit [Ping timeout: 258 seconds]
Asu has joined #yosys
kraiskil_ has joined #yosys
<sensille>
is it important to do tri-stating logic only at top level? technically it shouldn't matter if the hierarchy gets flattened upfront anyway
FFY00 has joined #yosys
kraiskil_ has quit [Ping timeout: 258 seconds]
kraiskil_ has joined #yosys
vidbina has joined #yosys
kraiskil_ has quit [Ping timeout: 256 seconds]
vidbina has quit [Ping timeout: 256 seconds]
kraiskil_ has joined #yosys
Asuu has joined #yosys
Asu has quit [Ping timeout: 260 seconds]
gmc has quit [Remote host closed the connection]
dys has joined #yosys
klotz has joined #yosys
kraiskil_ has quit [Remote host closed the connection]
ayazar has joined #yosys
jakobwenzel has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
Asu has joined #yosys
Asuu has quit [Ping timeout: 264 seconds]
mirage335 has quit [Ping timeout: 246 seconds]
mirage335 has joined #yosys
<tnt>
Does yosys have any attribute you can set to prevent it from messing / optimizing the carry chains ?
<tnt>
I'm guessing it tries to optimize stuff but doing so it prevents packing and so that makes things way worse and not better.
emeb has joined #yosys
<ZirconiumX>
Maybe a (* keep *)?
<ZirconiumX>
I mean, carry chains are whiteboxes
<ZirconiumX>
So only ABC9 can really "optimise" them
<tnt>
With abc9 the bottom lut ends up with the inputs not on the right ports for packing. Without it (so "old" abc), then the top luts end up with the input on the wrong ports for packing.
<tnt>
(because really it doesn't end up actually using any less luts or anything, just not using the right lut inputs for packing)
<ZirconiumX>
That...seems like a nextpnr thing?
<tnt>
nextpnr expects some specific lut input to be common to the SB_LUT4 and the SB_CARRY for them to be packable in the same LC.
gmc has joined #yosys
jakobwenzel1 has joined #yosys
<tnt>
Mmm, my understanding was that it was using \$__ICE40_CARRY_WRAPPER to avoid that kind of issue.
klotz has quit [Remote host closed the connection]
jakobwenzel1 has quit [Ping timeout: 240 seconds]
gmc has quit [Remote host closed the connection]
BinaryLust has joined #yosys
citypw has joined #yosys
gmc has joined #yosys
gmc has quit [Remote host closed the connection]
gmc has joined #yosys
vidbina has joined #yosys
bzztploink has joined #yosys
<tnt>
So the issue is the opt_lut pass
<tnt>
Mm ... yeah, I see the " -dlogic SB_CARRY:I0=2:I1=1:CI=0" which I assume is to prevent it from messing with I1/I2 that must stay in place for the SB_CARRY to stay there.
<tnt>
But there is nothing that prevents it from moving the signal coming from a SB_CARRY to I3 to somewhere else.
<ZirconiumX>
File a bug if you haven't already
<whitequark>
tnt: oh ugh I missed that
<whitequark>
opt_lut keeps being a PITA
<tnt>
I'm collecting info and trying to make the absolute minimum case.
<tpb>
Title: ice40: opt_lut can break carry packing by moving SB_CARRY out to another input than I3 · Issue #2061 · YosysHQ/yosys · GitHub (at github.com)
gmc has quit [Remote host closed the connection]
citypw has quit [Ping timeout: 240 seconds]
klotz has joined #yosys
BinaryLust has quit [Ping timeout: 256 seconds]
klotz has quit [Quit: klotz]
dys has quit [Ping timeout: 265 seconds]
rlee287 has joined #yosys
DaKnig has quit [Ping timeout: 272 seconds]
DaKnig has joined #yosys
vidbina has quit [Ping timeout: 260 seconds]
rlee287 has quit [Quit: Konversation terminated!]
rlee287 has joined #yosys
rlee287 has quit [Read error: Connection reset by peer]
adjtm_ has joined #yosys
adjtm has quit [Ping timeout: 256 seconds]
ayazar has quit [Quit: ayazar]
vidbina has joined #yosys
DaKnig has joined #yosys
DaKnig has quit [Changing host]
BinaryLust has joined #yosys
vidbina has quit [Ping timeout: 246 seconds]
dys has joined #yosys
Asu has quit [Remote host closed the connection]
az0re has quit [Remote host closed the connection]
<Forty-Bot>
is it possible to access module parameters from another module?