<adamgreig[m]>
finally getting back into fpga headspace and having enough moments of free time to remember this poor rfc
<whitequark[cis]>
excellent, thank you! ^^
<adamgreig[m]>
sorry it's been such a wait
<adamgreig[m]>
no more time tonight but hope to have a go prototyping the multi-bit implementation soon
<adamgreig[m]>
since i wrote that rfc i went on holiday abroad and while on holiday my house flooded and the repairs took until june at which point work suddenly got became busiest it's been since i joined 7 years ago, so it's been a bit manic!
<adamgreig[m]>
but after blowing up about seven student rocket engines in two weeks (and not destroying the rest of them) it's starting to calm down a bit
<whitequark[cis]>
amazing
cr1901 has quit [Read error: Connection reset by peer]
Degi has quit [Ping timeout: 248 seconds]
Degi has joined #amaranth-lang
cr1901 has joined #amaranth-lang
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #amaranth-lang
_whitelogger has joined #amaranth-lang
frgo has quit [Quit: Leaving...]
frgo has joined #amaranth-lang
vinh has joined #amaranth-lang
vinh has quit [Remote host closed the connection]
<RobTaylor[m]>
<whitequark[cis]> I wonder what happened to jfng
<RobTaylor[m]>
do we need to pull together a maintainer group for amaranth-soc? I'd also like to get the docs PR landed after a review.
<RobTaylor[m]>
<zyp[m]> yeah, amaranth-soc#58 provides an annotation with the registers of e.g. a peripheral block, and being able to attach additional annotations to give peripheral-specific metadata is useful
<RobTaylor[m]>
that seems useful for my next task - attaching software drivers to IP
<RobTaylor[m]>
zyp: i also have some cute code that uses pydantic for generating schemas with TypedDicts, if you're interested
<whitequark[cis]>
#58 has some open review comments
<whitequark[cis]>
re: maintainer group: i can do housekeeping tasks, but as of now there are no candidates i'm aware of who have remotely the same degree of skill, experience, and dedication as JF does
<RobTaylor[m]>
whitequark[cis]: true, but we probably should think of doing something if jf has gone awol :(
<whitequark[cis]>
any realistic solution will involve a significant proportion of time from me as either author or reviewer
<RobTaylor[m]>
for sure reviewer
<whitequark[cis]>
if JF has indeed disappeared, that means that the countless hours i spent discussing amaranth-soc with him and transferring domain knowledge will not benefit the project
<RobTaylor[m]>
whitequark[cis]: :(
<whitequark[cis]>
for me personally that makes it rather more difficult to justify doing it again, so i am biased towards looking for someone with many years of SoC experience already
<RobTaylor[m]>
for now, even just us landing #58 and #82 would be a win for me... gatecat has been also putting some effort in on AXI
<whitequark[cis]>
for better or worse i've already prepared for setting the course for amaranth-soc that will pay off in the coming years
<whitequark[cis]>
i haven't reviewed #82 and #58 needs changes
<whitequark[cis]>
i'll get around to it eventually, if you want it faster you can contract me
<RobTaylor[m]>
hah, yes, that's certainly on my list once i can :)
<whitequark[cis]>
a community contributor has also been talking about AXI (two, actually) and that's something i also have on my list to discuss
<whitequark[cis]>
we should probably deprecate Wishbone and use AXI Lite as the default interconnect for -soc
<RobTaylor[m]>
whitequark[cis]: agreed. I'll try to get gatecat to join in the discussions...
<whitequark[cis]>
meeting in 25 minutes
<whitequark[cis]>
good evening everyone, it is time for our weekly meeting. who is attending?
<whitequark[cis]>
does anyone have any comments on the substance of the RFC?
<tpw_rules>
this seems quite reasonable, am an enjoyer of the corresponding asyncio methods
<tpw_rules>
i am okay with gather, it matches the original. though the use case is different
<whitequark[cis]>
vup @libera_vup:catircservices.org, Wanda: any opinions on functionality?
<tpw_rules>
i think Task needs at least .done() too and to define what exception is raised if not finished
<tpw_rules>
(that second part may be less necessary since Task currently cannot encapsulate an exception)
<Wanda[cis]>
I don't think I have enough async experience to say much here
<Wanda[cis]>
looks good on the surface
<Wanda[cis]>
is there an implementation already?
<whitequark[cis]>
Wanda[cis]: no, which is why i wanted to keep it very simple (no cancellation semantics)
<Wanda[cis]>
hrm.
<whitequark[cis]>
tpw_rules: hm, could add .done() though it doesn't seem super useful rn
<Wanda[cis]>
well... it should be fine
<tpw_rules>
i guess in most cases you do not care about the result anyway?
<whitequark[cis]>
yeah
<whitequark[cis]>
usually if you care about the result you just await it
<vup>
Do I understand the RFC correctly that with the suggested (absence) of exception propagation, I would have no way to for example catch the TimeoutExecption raised by the suggested timeout helper?
frgo has joined #amaranth-lang
<whitequark[cis]>
correct
<vup>
hmm.
<whitequark[cis]>
i don't believe we have the resources to develop sound cancellation semantics, and i don't want unsound ones
<tpw_rules>
are they not the same as asyncio's?
<whitequark[cis]>
asyncio's cancellation is awful
<tpw_rules>
then rip from trio?
<tpw_rules>
(i thought that's what asyncio did there)
<whitequark[cis]>
tpw_rules: yes for task groups
<whitequark[cis]>
tpw_rules: you're saying it like it's a trivial thing
<whitequark[cis]>
i will suggest volunteering an implenentation :p
<tpw_rules>
yes i think it's fine to defer
<tpw_rules>
can you remind the background of why not just use some pieces of async directly?
<whitequark[cis]>
we are using pieces of async: coroutines
<whitequark[cis]>
we can't use asyncio because we're not doing io and because none of the internals are public or stable
<tpw_rules>
then what does our implementation of task groups do special?
<whitequark[cis]>
everything?
<whitequark[cis]>
it's completely ground up custom
<tpw_rules>
i guess we don't have an asyncio-compatible loop and ancestor task is what you mean
frgo_ has joined #amaranth-lang
<whitequark[cis]>
coroutines are just generator functions with better syntax, async syntax and asyncio are basically unrelated
<whitequark[cis]>
tpw_rules: correct. there's nothing about async functions that ties them to asyncio or even makes it easier
frgo has quit [Ping timeout: 248 seconds]
<whitequark[cis]>
all of the scheduling and waiting logic is up to the library you feed them to
<tpw_rules>
well this is a pretty clean surface if we decide to change out the guts later, or add capability like cancelation
<whitequark[cis]>
yep!
<tpw_rules>
will the task drop cause python to whine? it's necessary to prevent the timeout from occurring thoug
<whitequark[cis]>
it might and we'll have to fix that
<tpw_rules>
i forget the available options and if that changes the API surface
<whitequark[cis]>
we already have that problem
<whitequark[cis]>
it happens in the trigger machinery
<tpw_rules>
okay. i think i'm out of cogent thoughts. i like `gather` for familiarity
<vup>
I would say I am at the same point, seems like a good stepping stone, but exception propagation / cancellation semantics seem like something that would be very desireable, atleast down the line.
<whitequark[cis]>
I fully agree
<whitequark[cis]>
Wanda, tpw_rules, vup @libera_vup:catircservices.org: merge with addition of .done()?
<vup>
Fine by me
<tpw_rules>
yes
<Wanda[cis]>
yeah
<whitequark[cis]>
any comment on names?
<whitequark[cis]>
i guess everyone's fine with copying asyncio
<whitequark[cis]>
disposition for RFC 80: merge
<whitequark[cis]>
this is the end of the meeting. thanks everyone who participated!
<whitequark[cis]>
it also has quite a bit of focus on timeouts which isn't relevant in the same way for RTL, where your timeouts are mostly just making sure the simulation doesn't run forever waiting on some error (i.e. if you're in the timeout case it's nowhere as important for it to be precisely at the deadline)
adamgreig_ has quit [Server closed connection]
adamgreig_ has joined #amaranth-lang
<whitequark[cis]>
on the other hand, maybe better support for timeouts will help people find their own use for such functionality
<whitequark[cis]>
either way, i think an implementation of cancellation would be in order before an RFC
Xesxen has quit [Server closed connection]
Xesxen has joined #amaranth-lang
<zyp[m]>
sorry I missed the meeting
<zyp[m]>
<vup> Do I understand the RFC correctly that with the suggested (absence) of exception propagation, I would have no way to for example catch the TimeoutExecption raised by the suggested timeout helper?
<zyp[m]>
not from a testbench function, but you can catch it where you invoked sim.run()
<zyp[m]>
I've mostly been using timeouts in unit tests to keep test cases from getting stuck, in which case it's not interesting to catch them anyway, but let them propagate to the unit testing framework
<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] whitequark 1881a0b - Deploying to main from @ amaranth-lang/rfcs@3e738b09fb20e886fada02f099c45619f0bde7e4 🚀
pie_ has quit []
AhmedCharles[m] has joined #amaranth-lang
<AhmedCharles[m]>
For what it's worth, I read RFC#15 and it makes complete sense. :)