FFY00_ has quit [Read error: Connection reset by peer]
FFY00 has joined #amaranth-lang
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #amaranth-lang
Degi has quit [Ping timeout: 276 seconds]
Degi has joined #amaranth-lang
roflin has quit [Quit: WeeChat 4.5.2]
roflin has joined #amaranth-lang
<whitequark[cis]>
i've forgotten to connect the output of a something-encoder enough times that i feel like we need a must_use annotation
zyp[m] has joined #amaranth-lang
<zyp[m]>
sounds reasonable; what would it be attached to, and when would it be checked?
<whitequark[cis]>
that's the question, isn't it? i'm thinking to the `Member
<whitequark[cis]>
* the `Member`
<whitequark[cis]>
as for the checking semantics, it's unclear
<whitequark[cis]>
which is why it's a message in a chat and not an RFC
<zyp[m]>
yeah, I'm asking the questions I figure needs to be discussed
<zyp[m]>
one point on the checking is «should it only check for wiring.connect() connections, or should it check for any use in expressions of the contained signals?
<zyp[m]>
s//`/, s//`/, s/?/?»/
<zyp[m]>
I don't think the latter is very practical, and the former seems a bit too limiting
<whitequark[cis]>
why is the latter not practical?
<zyp[m]>
in the former case, we might also need e.g. a wiring.mark_used() for when a member is consumed by something other than connect()
<zyp[m]>
(like a gasket/adapter or whatever)
<zyp[m]>
the latter would need a bunch of heuristics for when something is considered used
<whitequark[cis]>
for Out members: sampled outside of the module that drives it. for In members: driven
<zyp[m]>
what about signature members? any or all child members?
<whitequark[cis]>
all
<zyp[m]>
I'm concerned about the potential for false positives
<whitequark[cis]>
what is a false positive, in this context?
<zyp[m]>
how does the equivalent of (void)foo; look in amaranth? m.d.comb += Signal().eq(foo)?
<whitequark[cis]>
I don't see this scheme ever having false positives though? it's using accurate netlist based information, if it's not in the netlist, it's definitely not used
<zyp[m]>
I'm thinking of a case where you have a must_use parent with a child that's not always useful, but still inherits the must_use annotation
<whitequark[cis]>
well, don't do that
<whitequark[cis]>
I would expect that stream.Signature would take its own must_use argument for example, and set the annotation only on valid/ready
<whitequark[cis]>
(although I'm not even sure about that, maybe on streams it's fine to always do it?)
<zyp[m]>
I was also thinking of streams, before realizing that the payload is considered a single signal anyway
<whitequark[cis]>
yes
<zyp[m]>
so any optional sideband signals packed in the payload still wouldn't count if the rest of the payload is used
<whitequark[cis]>
I actually can't think of a case where you'd need to use ready/valid so much that you annotate them as must-use, but not care about the payload
<zyp[m]>
I agree
<whitequark[cis]>
so for a stream it should probably just be applied to all of them (with the caveat that on always-ready/valid streams, you don't need to use the constant, not that we can detect that anyway)
<zyp[m]>
but I have used streams where last exists in an advisory manner
<whitequark[cis]>
yeah, that would be fine under this proposal
<whitequark[cis]>
we technically have access to bit-level netlist data so we could detect this somehow, but this would require extending ShapeCastable further, or at least allowing a bit-resolution must-use annotation on signals
<zyp[m]>
I think it makes sense to keep it on the signal level
<whitequark[cis]>
not even for gateware, i feel like i've used it significantly more to compute custom one-off CRCs in Python than i've used it for gateware; it's simply too convenient
<tpw_rules>
(it's very old fashioned but i like crcmod for its speed)
<whitequark[cis]>
yeah, I'd probably use crc if I needed something faster
<tpw_rules>
oh huh that one looks newer than when i last needed one, thanks for the tip
adamgreig[m] has joined #amaranth-lang
<adamgreig[m]>
<whitequark[cis]> "adamgreig: very happily using..." <- 💙 glad to hear it!
<adamgreig[m]>
Also sorry I am happy to get that lfsr pr back up to date, but I've been at rustweek all week and the conference schedule always takes me by surprise
<whitequark[cis]>
that's completely okay, no rush
jjsuperpower has joined #amaranth-lang
jjsuperpower has quit [Remote host closed the connection]