whitequark changed the topic of #yosys to: Yosys Open SYnthesis Suite: https://github.com/YosysHQ/yosys/ | Channel logs: https://libera.irclog.whitequark.org/yosys/ | Bridged to #yosys:matrix.org
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
ppisati has quit [Ping timeout: 240 seconds]
ppisati has joined #yosys
ppisati has quit [Ping timeout: 240 seconds]
ppisati has joined #yosys
ppisati has quit [Ping timeout: 252 seconds]
ppisati has joined #yosys
ppisati has quit [Ping timeout: 240 seconds]
nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #yosys
ppisati has joined #yosys
killjoy has joined #yosys
killjoy has joined #yosys
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #yosys
<cr1901> I don't have code to share immediately right now, but I found a load-bearing comment that when altered changes yosys' synth_ice40 LUT usage from 860 LUTs to 808 LUTs. Uhhh...
<lofty> cr1901: amazing
<lofty> which one? :p
<cr1901> Not in yosys, in my design (generated from Amaranth). I would expect comments to uhhh... not change the synthesis results that much.
<cr1901> Must be a next-gen optimization
FabM has joined #yosys
FabM has quit [Changing host]
FabM has joined #yosys
<cr1901> Is there a way to change yosys' PRNG seed? Only thing I can think of, unless somehow "attribute enum_values" are special (seems like yosys and Amaranth just emit them, not use them)
<cr1901> This is tomorrow me's problem
dormito has quit [Ping timeout: 258 seconds]
dormito has joined #yosys
bjorkint0sh has joined #yosys
bjorkintosh has quit [Ping timeout: 240 seconds]
bjorkint0sh has quit [Ping timeout: 258 seconds]
bjorkint0sh has joined #yosys
ec has quit [Remote host closed the connection]
ec has joined #yosys
cr1901_ has joined #yosys
cr1901 has quit [Ping timeout: 260 seconds]
bjorkint0sh has quit [Ping timeout: 248 seconds]
unkraut has quit [Remote host closed the connection]
unkraut has joined #yosys
<Myrl-saki> `always @*` vs `assign` doesn't seem to always have the same behavior.
<Myrl-saki> Heck, `if (p) begin q; r; end` is sometimes different as `if (p) q; if (p) r;`
<Myrl-saki> What's the reason for this?
<lofty> What do you mean by "same behaviour"?
<Myrl-saki> Right, that was a bit vague lol sorry. I mean that it doesn't have the same resource usage.
<lofty> Well, you do have to consider that Yosys is chaotic; small changes in the source code can have pretty big changes elsewhere
<lofty> Due to things like hashing and such
arogora has joined #yosys
<Myrl-saki> Ahh thanks. And yeah, I see. So from the PoV of Yosys (as a graph? or RTL?), they're basically the same, but the order that things get applied differ, thus resulting in different resource usage?
<lofty> Yeah
killjoy has quit [Ping timeout: 252 seconds]
arogora is now known as killjoy
killjoy has quit [Changing host]
killjoy has joined #yosys
<lofty> A big factor in this is, for example, that Yosys carries source code information around
<lofty> Like where a cell was defined
<Myrl-saki> Yeah, I see now. Even changing the order of the assigns change the behavior lol
<Myrl-saki> Err, not behavior.
bjorkintosh has joined #yosys
bjorkintosh has quit [Changing host]
bjorkintosh has joined #yosys
<Myrl-saki> This is not exactly related, but I feel like I'm getting a very huge "told you so" moment since my shifter is actually the critical path right now. :x
<Myrl-saki> Now I'm curious how much the order matters!
<Myrl-saki> Wild, I think changing the order worked.
xiretza[cis] has joined #yosys
<xiretza[cis]> for some definition of "worked"
<Myrl-saki> Hm, why does it say the critical path is slower, but the frequnecy can be higher?
dys has quit [Remote host closed the connection]
<lofty> You're going to have to provide more information than that :p
<lofty> it...doesn't say the critical path is slower?
<lofty> it says it's faster
<lofty> optimized: Info: 8.6 ns logic, 12.6 ns routing
<lofty> unoptimized: Info: 9.4 ns logic, 13.4 ns routing
<Myrl-saki> OH. The calculation is based on posedge -> posedge. What does 'posedge sysclk' -> <async> say?
<Myrl-saki> Like, what does it erm, mean?
<lofty> Those refer to timings outside of clock domains, like, to GPIO
cr1901_ is now known as cr1901
chaoticryptidz has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
chaoticryptidz has joined #yosys
chaoticryptidz has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
chaoticryptidz has joined #yosys
FabM has quit [Ping timeout: 272 seconds]
tlwoerner_ has joined #yosys
tlwoerner has quit [Ping timeout: 260 seconds]
chaoticryptidz has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
chaoticryptidz has joined #yosys
tlwoerner_ has quit [Ping timeout: 260 seconds]
tlwoerner has joined #yosys
<Myrl-saki> I might have found something weird.
Myrl-saki has left #yosys [WeeChat 4.0.2]
Myrl-saki has joined #yosys
<Myrl-saki> Sigh, what's wrong with Weechat.
<Myrl-saki> log("meow %d", A.chunks()[0].wire->name.index_);
<Myrl-saki> sig_alu[RTLIL::SigSig(A, B)].insert(alunode);
<Myrl-saki> If I load any file before it, I get this.
Myrl-saki has quit [Quit: WeeChat 4.0.2]
Myrl-saki has joined #yosys
<Myrl-saki> meow 713 creating $alu model for $macc $sub$au.v:20$86.
<Myrl-saki> meow 712 creating $alu model for $lt$au.v:22$88 ($lt): 2 new $alu
<Myrl-saki> Despite it being connected to the same wire.
<Myrl-saki> Ah, there's the yosys_xtrace option
<Myrl-saki> Ah, found why. It's simpler than that.
nonchip has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nonchip has joined #yosys
<Myrl-saki> This line only sometimes runs. if (!subtract_b && B < A && GetSize(B)) {
<Myrl-saki> So
<Myrl-saki> I think the point is canonicalization?
<Myrl-saki> Hm, I don't think I know enough to make judgment. >_<
<Myrl-saki> What's happening is that this converts `a + b` to `b + a` sometimes, which hinders unification with `a - b`.
<Myrl-saki> There's the obvious "just remove this canonicalization" but I'm pretty sure that hinders other optimizations.
<Myrl-saki> (Also, that's not actually the problem, even.)
<Myrl-saki> Well that's fun.
<Myrl-saki> I understand the problem now.
<Myrl-saki> Turns out that cmp also has this canonicalization.
<Myrl-saki> The problem is then that cmps can swap, but subtracts cannot.
<Myrl-saki> (I'm not a C++programmer so :x)
tpb has quit [Ping timeout: 246 seconds]
<Myrl-saki> Though, I think this idea is correct. The code itself may not be though. xd
<Myrl-saki> Oh wait
<Myrl-saki> I don't even need the swapped, do I
tpb has joined #yosys
<Myrl-saki> Okay, I think I'm happy with this. :)
<Myrl-saki> Ah.
<Myrl-saki> I found a failing test.
<Myrl-saki> Though, I think this is supposedly unobservable behavior.
<Myrl-saki> FWIW, now that I think about it, I don't have to remove the initial swap.
<Myrl-saki> Because cmp now just acts as if sig_alu is an order-independent dictionary.
<Myrl-saki> What's the `GetSize(B)` check there for?
<Myrl-saki> Ah