anubis has quit [Remote host closed the connection]
<d1b2>
<vipqualitypost> so looking through some materials written by various people that mostly pre-dates amaranth (using nmigen): what's the difference between yield Settle() and yield Tick() and when should you use one or the other or neither for simulating?
<d1b2>
<vipqualitypost> maybe that is vague: I am using amaranth, but the materials I am looking at are written with nmigen- are settle and tick still things and when should they be used?
<charlottia>
They are still things. Tick() advances the simulation one clock cycle (by default in the sync domain). It's also the default default action in a sync process added to a simulation, i.e. yield on its own is equivalent to Tick().
Qyriad has joined #amaranth-lang
<d1b2>
<vipqualitypost> is settle like a tick but on a smaller timescale for comb logic?
peepsalot has quit [Quit: Connection reset by peep]
<charlottia>
More or less — it'll not advance the simulation time, but let processes run while comb logic resolves to a stable point (settles).
<d1b2>
<vipqualitypost> ok, makes sense. and so presumably comb logic should be resolved by the end of any tick, right? i.e. I only need to use settle in some special cases where I specifically don't want to wait for a full cycle?
peepsalot has joined #amaranth-lang
leptonix has quit [Server closed connection]
leptonix has joined #amaranth-lang
<charlottia>
I think that's true except when you're messing with the DUT directly from the simulator. I haven't looked into the exact behaviour myself, but e.g. I've found sometimes when I permute things and Tick() but don't Settle(), the behavior can be different to what I expect when there's comb logic downstream of it.
<d1b2>
<vipqualitypost> interesting, I will keep that in mind! thank you for the help!
Qyriad has quit [Quit: Connection closed for inactivity]
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 47817a0 - Deploying to main from @ amaranth-lang/amaranth@7e438180e08f72fd5d960d279bc4f0051bdb5e42 🚀
<fl4shk[m]>
<adamgreig[m]> "libera are ending portalling..." <- dang it, and I just switched to Matrix, too
<whitequark>
this room isn't bridged
<whitequark>
also from discussions I had, this is primarily on the Matrix side which is ... not doing so well
<galibert[m]>
You mean Matrix in general is not doing well?
<galibert[m]>
Or just the bridging stuff?
<fl4shk[m]>
I can switch back to IRC
<fl4shk[m]>
I liked Matrix though
<whitequark>
given a binary choice between IRC and Matrix it will be Matrix for me
<whitequark>
and for all of the channels I operate
<fl4shk[m]>
I see
<fl4shk[m]>
that sounds good!
<whitequark>
but it's not a binary choice (yet?)
<fl4shk[m]>
most of what I use Matrix for is this channel anyway
<fl4shk[m]>
oh
<fl4shk[m]>
Yeah
<galibert[m]>
ok, went through the configs, there are some nice options in there
<galibert[m]>
including not fetching ulrls by default, should make the commits way less noisy in there
<robtaylor>
I would love if #amaranth was on matrix :)
<galibert[m]>
it....is?
<robtaylor>
i mean properly...
<robtaylor>
the bridge gets a bit annoying at times..
<galibert[m]>
Catherine is on matrix, so it's properly there, everywhere else is improper
<robtaylor>
hah, yes, but eveything gets munged through irc semantics at the moment
<whitequark>
I use IRC through Matrix, which is intentional
<whitequark>
Matrix to me is essentially a bouncer
<robtaylor>
same here
<charlottia>
The inline code spans all getting some weird unicode prefix on the IRC(/Discord) side is off-putting, and the truncation is super annoying.
<whitequark>
the prefix is actually an mIRC code I think
<charlottia>
whitequark: Likewise, literally replaced my IRC bouncer with it!
<whitequark>
so it's standard-ish (as much as IRC things are standard)
<charlottia>
whitequark: Ohhhhhhhhhh lmao, that makes sense.
<charlottia>
nod!
<whitequark>
the truncation is pretty bad yeah
<fl4shk[m]>
whitequark: me too
FL4SHK has joined #amaranth-lang
<fl4shk[m]>
maybe I should write or find a Matrix bridge to host locally for just me
<galibert[m]>
something wrong with the matrix web interface?
<fl4shk[m]>
well
<fl4shk[m]>
Libera is making the Matrix bridge opt-in
<fl4shk[m]>
and that's a problem for me because I wanted to use Libera from my phone
<galibert[m]>
which is rather sane when you think about it
<fl4shk[m]>
I agree that it's sane, but one of the channels I'm in has no ops at all
<fl4shk[m]>
so it won't be bridged opt-in
<fl4shk[m]>
and also there are other channels that I don't know whether they'd opt-in
<fl4shk[m]>
admittedly I couldn't figure out how to join libera channels that start with ## from Matrix
<whitequark>
if you read between the lines of the announcement, it looks like they want it opt-in because they don't trust the Matrix side of things (hence mentions of +s)
<whitequark>
this is my speculation
<galibert[m]>
yeah, reads like that
<whitequark>
and I do know that the Libera folks have no say in how the bridge is run (this is well described if you look)
<galibert[m]>
So unreliable, acceptance not under control of the libera side, and ignoring some channel modes, not surprising they consider the situation suboptimal
<whitequark>
yep
<galibert[m]>
they may have used stronger words at some point too, I suspect
<FL4SHK>
gotcha
<FireFly>
it's been sort of a long-running problem
<galibert[m]>
slicing an integer is not very complicated. val[a:b] = (val >> a) & ((1 << (b-a)) - 1)
<FL4SHK>
true
<zyp[m]>
if I had to work on bits like that in python, I'd make a generator like this that produces the indexes of the bits: https://paste.jvnv.net/view/LpNwD
<zyp[m]>
finding the first bit then becomes next(bits_set(n)) and the count of ones becomes sum(1 for _ in bits_set(n))