whitequark[cis] changed the topic of #amaranth-lang to: Amaranth hardware definition language · weekly meetings: Amaranth each Mon 1700 UTC, Amaranth SoC each Fri 1700 UTC · play https://amaranth-lang.org/play/ · code https://github.com/amaranth-lang · logs https://libera.irclog.whitequark.org/amaranth-lang · Matrix #amaranth-lang:matrix.org
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 245 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 246 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 264 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 246 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 245 seconds]
buganini has joined #amaranth-lang
Degi has quit [Ping timeout: 252 seconds]
buganini has quit [Ping timeout: 246 seconds]
Degi has joined #amaranth-lang
buganini has joined #amaranth-lang
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
cyrozap has joined #amaranth-lang
<purdeaandrei[m]> Is there something akin to asyncio.create_task in amaranth?
<purdeaandrei[m]> or asyncio.gather?
<whitequark[m]> not currently (adding it would require an RFC)
<purdeaandrei[m]> So at the moment, the only way I can achieve perceived parallelism is by adding a testbench or process, right?
<whitequark[m]> yes
buganini has quit [Ping timeout: 245 seconds]
<purdeaandrei[m]> Can I create (and destroy?) a testbench at runtime
<whitequark[m]> only before the simulator starts running
buganini has joined #amaranth-lang
<purdeaandrei[m]> Is there any way I can create a 1ns delayed version of an expression? (or to look at the value of an expression from the past?) ctx.changed() only accepts Signals. Which makes sense I think, the simulator would need to know to recalculate the value of the expression every time one of its dependencies changes, so I guess I would have to wrap my expression as a Signal, but I can't drive that signal with ctx.set, cause it doesn't
<purdeaandrei[m]> solve my problem I still want to wait on changes of the signal, it would have to be something like `m.d.comb += ` but I think there's no way to schedule something like that from a testbench, unless I make it part of a dut?
<vegard_e[m]> ideally ctx.changed() should accept expressions
<purdeaandrei[m]> I guess it could, but it doesn't right now
buganini has quit [Ping timeout: 246 seconds]
<_whitenotifier-1> [amaranth] purdeaandrei commented on issue #1508: Broken Trigger when for TriggerCombination delay/changed expires at the same time - https://github.com/amaranth-lang/amaranth/issues/1508#issuecomment-2337284655
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 246 seconds]
john2 has joined #amaranth-lang
<_whitenotifier-1> [amaranth] whitequark commented on issue #1508: Broken Trigger when for TriggerCombination delay/changed expires at the same time - https://github.com/amaranth-lang/amaranth/issues/1508#issuecomment-2338294519
<zyp[m]> Catherine: Just noticed I missed the `deadline` argument of `Simulator.run_until()` in RFC 66. I will include it in the implementation; should we also go back and update the RFC?
<whitequark[cis]> sure
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #amaranth-lang
<zyp[m]> what's the policy for tests and deprecated code? do I just update all test cases calling Simulator.add_clock() and friends to pass a Period and drop the deprecated form?
<whitequark[cis]> I'd say copy them and modify the old ones to suppress the warning
<whitequark[cis]> good evening everyone, it is time for our scheduled Monday meeting
<whitequark[cis]> who's attending?
jfng[m] has joined #amaranth-lang
<jfng[m]> o/
<cr1901> Isort of
galibert[m] has joined #amaranth-lang
<galibert[m]> Vaguely
<zyp[m]> o/
<Wanda[cis]> meow (I may or may not drop randomly)
Chips4MakersakaS has joined #amaranth-lang
<Chips4MakersakaS> I will be preparing food at the same time; so not really attending.
<galibert[m]> we're really a sorry-ass group :-)
<whitequark[cis]> please respond with your comments or disposition: merge or close
<cr1901> merge
<jfng[m]> > This will add an implied requirement for a ValueCastable to implement .eq() to be usable with lib.wiring.
<jfng[m]> i don't see this as a drawback; not implementing `.eq()` would communicate that the ValueCastable is immutable
<galibert[m]> merge, do you expect automatic insertion of adapters at some point in the future?
<whitequark[cis]> mine is merge; RFC looks good, the language is extended in a natural way, and because of the 1-version grace period, if we are making a mistake, we have ample opportunity to revert it partly or in full
<whitequark[cis]> I do not expect automatic insertion of adapters to ever be a part of the language
<galibert[m]> ok, I tend to agree, explicit is probably better
<whitequark[cis]> (you could make a wrapper around connect that does it, since connect isn't magic)
<Wanda[cis]> the RFC presumably should also apply to EnumView?
<whitequark[cis]> ah, good point
<jfng[m]> merge
<zyp[m]> Wanda[cis]: I thought enums already were typesafe, but I see now that only goes for comparisons, not `.eq`
<zyp[m]> so yeah, it'd make sense to include EnumView too
<whitequark[cis]> Wanda: all good with the modification?
<Wanda[cis]> hm
<Wanda[cis]> I think so, yes
<Wanda[cis]> or
<Wanda[cis]> need to look somehting up
<Wanda[cis]> ... ah Struct is a subclass, good
<whitequark[cis]> yeah
<whitequark[cis]> View is intended to be inherited from (so long as you don't break the base class)
<Wanda[cis]> "If other is a View, reject the assignment if layouts are not identical"
<Wanda[cis]> I'd say something different
<Wanda[cis]> namely, it should depend on other's shape, not type
<Wanda[cis]> for one, we also have data.Const to deal with
<Wanda[cis]> second, the RFC as written allows assigning a Value to a struct, but doesn't allow assigning ArrayProxy (because it counts as a non-View ValueCastable)
<zyp[m]> hmm
<whitequark[cis]> so "if the other is a View, reject the assignment if its .shape() isn't a data.Layout"?
<Wanda[cis]> I think Layout.cast may have to be involved, even
<whitequark[cis]> this is getting kind of complicated, but, hm
<whitequark[cis]> yeah
<Wanda[cis]> anyway
<zyp[m]> the issue is that currently it's only the .eq target that can indicate compatibility or not, we still don't have a reflected .eq that can say «this ValueCastable can be assigned to anything that accepts a Value»
<Wanda[cis]> I'm... concerned that the current state of value/shape-castables is kinda an ad-hoc mess
<zyp[m]> (relfected .eq came up in RFC 28 discussions)
<Wanda[cis]> while I don't really have anything against this RFC in particular, it feels like it's adding even more complexity
<Wanda[cis]> to an area that's already hard to understand
<whitequark[cis]> I generally agree but I also don't see how we could avoid it
<whitequark[cis]> the writing was on the wall by the time connect was added
<whitequark[cis]> it's basically the C++ problem of extending an overly simple language in a backwards-compatible way getting overly complex
<zyp[m]> I can amend the RFC to not reject non-view value-castables
<Wanda[cis]> yeah I don't think I have a solution either
<whitequark[cis]> zyp[m]: I think we can proceed with it as-is
<zyp[m]> what about ArrayProxy?
<Wanda[cis]> we do need to at least allow data.Const
<zyp[m]> agreed
<whitequark[cis]> would ArrayProxy be redefined on top of Choice which does the shape comparison thing?
<whitequark[cis]> that makes Choice a requirement for the 0.6 release
<whitequark[cis]> we ran out of time for today
<zyp[m]> I'll update the RFC for next week, including enum.EnumView and data.Const and look at specifying the exact check conditions better
<zyp[m]> and if I have time maybe I'll do a proof of concept too
<zyp[m]> speaking of 0.6, do we have a roadmap yet?
<_whitenotifier-1> [rfcs] whitequark commented on pull request #73: Add RFC for stricter connections. - https://github.com/amaranth-lang/rfcs/pull/73#issuecomment-2338768599
<whitequark[cis]> zyp: only that we should probably land the clock domain redesign
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 252 seconds]
indy has quit [Ping timeout: 248 seconds]
indy has joined #amaranth-lang
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #amaranth-lang
Lord_Nightmare has quit [Quit: ZNC - http://znc.in]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #amaranth-lang
Lord_Nightmare has joined #amaranth-lang
cr1901 has quit [Client Quit]
cr1901 has joined #amaranth-lang
jjsuperpower has joined #amaranth-lang
jjsuperpower has quit [Remote host closed the connection]
jjsuperpower has joined #amaranth-lang
indy has quit [Ping timeout: 252 seconds]
indy has joined #amaranth-lang
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 260 seconds]
phoenicianepic has joined #amaranth-lang
phoenicianepic has quit [Client Quit]
jjsuperpower has quit [Quit: Leaving]