00:44 <_whitenotifier-3> [rfcs] adamgreig opened pull request #72: Add LFSR generator to standard library - https://github.com/amaranth-lang/rfcs/pull/72

00:45 <_whitenotifier-3> [rfcs] adamgreig edited pull request #72: Add LFSR generator to standard library - https://github.com/amaranth-lang/rfcs/pull/72

03:46 <_whitenotifier-3> [amaranth] whitequark commented on pull request #1475: docs/stdlib/fifo: document fifo stream interfaces - https://github.com/amaranth-lang/amaranth/pull/1475#issuecomment-2268115509

08:15 <key2> how can I have a pin that is an IO, but only use DDRBuffer on the input part, and not the output ?

09:26 <_whitenotifier-3> [amaranth] purdeaandrei commented on pull request #1475: docs/stdlib/fifo: document fifo stream interfaces - https://github.com/amaranth-lang/amaranth/pull/1475#issuecomment-2268600902

12:01 <whitequark[cis]> <key2> "how can I have a pin that is..." <- assign .o to x.replicate(2)

12:04 <key2> that would mean that it would still go through the DDR, and have a delay. Unless I didn't understand well your answer

12:05 <zyp[m]> yes, it'll still be registered

12:06 <zyp[m]> I think you'll have to piece together vendor primitives to get what you want, assuming the platform you're using even supports it

12:07 <key2> I could in fact do it with the primitive of the vendor (GOWIN has a ODDR/IDDR)

12:53 <zyp[m]> <mcc111[m]> "so, i bodged a compose operator..." <- > <@mcc111:matrix.org> so, i bodged a compose operator https://github.com/mcclure/analogue-core-template-amaranth/blob/supersaw/src/fpga/amaranth_core/embed_amaranth_core/build.py#L26... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/yxmWaAaZNNorsBadUGKKXhtW>)

12:55 <whitequark[cis]> (that said--without having read the code--I think synchronizing between processes is potentially a valid use case and the way you'd go about it currently is using Signal edges as sync primitives)

12:56 <zyp[m]> if you've got one process that's generating a clock and another process that's simulating logic on that clock, then the second process should be triggered by the edges generated by the first process, and that relationship would give you an inherent execution order

12:57 <zyp[m]> and yeah, explicit sync signals should work too

12:59 <zyp[m]> also, this makes no sense: https://github.com/mcclure/analogue-core-template-amaranth/blob/supersaw/src/fpga/amaranth_core/embed_amaranth_core/build.py#L26

12:59 <zyp[m]> simulate_fake_clock() is an endless loop that never returns, so fn() would never get called

13:03 <jfng[m]> mildly related: when using signals to synchronize between testbenches, is there a way to make them appear in the VCD ?

13:03 <jfng[m]> e.g. https://github.com/jfng/amaranth/blob/fix-async-fifo-reset/tests/test_lib_fifo.py#L410

13:05 <jfng[m]> such signals are only accessed by simulation logic, not by the RTL design

13:11 <whitequark[cis]> put them in traces=[]

13:12 <jfng[m]> missed that, thanks

14:57 <mcc111[m]> <zyp[m]> "> <@mcc111:matrix.org> so, i..." <- one of my processes is generating the clock used by the other, because i'm in an unusual situation where `add_clock` is not available.

14:58 <zyp[m]> sure, but that shouldn't matter

14:58 <zyp[m]> any process triggered by a clock edge would necessarily execute after the process generating that edge

14:58 <mcc111[m]> <zyp[m]> "simulate_fake_clock() is an..." <- so i thought python async was supposed to work like generators/coroutines

14:58 <mcc111[m]> and i hoped one await would run until one await and then vice versa. i may be mixing up multiple generations of python async :(

14:59 <zyp[m]> they are coroutines, but doesn't work like you imagine

14:59 <mcc111[m]> s/await/yield/

15:00 <mcc111[m]> are the amaranth processes supposed to be async def at all? those were defs until i started fiddling with it yesterday

15:00 <mcc111[m]> asked a different way, are async and yield paired?

15:00 <zyp[m]> the new simulator interface makes them all async

15:00 <mcc111[m]> mcc111[m]: if the answer to this is no then that's great because i know which documentation to read to learn what python concept i have wrong :P

15:01 <zyp[m]> only async functions can use await

15:01 <mcc111[m]> zyp[m]: "new" is this last month?

15:01 <zyp[m]> await roughly replaces the use of yield in the old simulator interface

15:01 <mcc111[m]> okay

15:01 <mcc111[m]> so i'm not just acting arbitrarily, something actually did change

15:03 <zyp[m]> yes, RFC 36 happened

15:05 <mcc111[m]> if my goal is to upgrade code from pre- to post- RFC 36, would reading RFC 36 likely be enlightening in a way that the current simulator docs would not?

15:06 <zyp[m]> the simulator docs were written after RFC 36 and documents the new interface, and should be a better resource than the RFC itself

15:07 <mcc111[m]> ok

15:08 <mcc111[m]> <zyp[m]> "if you've got one process that's..." <- ok i see how this would work now

15:38 <whitequark[cis]> there will be no formal meeting today (I need rest) but I encourage everyone to discuss the latest RFC PR, the LFSR proposal

15:38 <whitequark[cis]> I actually haven't looked at it yet, but I do know that I'm excited to use it

16:05 <antoinevg[m]> Stupid-amaranth-soc-QuestionMondays:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HOxpdEPOBduvqIcQFrsGjQIR>)

16:13 <jfng[m]> this is normal, all fields of the register are updated on a write

16:17 <jfng[m]> also, csr writes are atomic, so if you have a 32b register behind an 8b CSR bus, then the written values are buffered until the last 8b write (to the upper address), then the register gets updated atomically

16:17 <antoinevg[m]> Cool, tx jfng !