<_whitenotifier-9>
[amaranth-lang/amaranth-yosys] whitequark cdc3df1 - [autorelease] Update wasmtime version requirement from <7 to <8.
<d1b2>
<jer_emy> what is the correct/expected way to create a list of signals (ie a 2D array)? Currently this works: self.inputs = [] for i in range(channel_count): self.inputs.append(Signal(bit_depth)) whereas this only creates a copy of the same signal object multiple times: self.inputs = [Signal(bit_depth)] * channel_count
<d1b2>
<bob_twinkles> the latter is a native python behavior, nothing amaranth has done. You can experiment with this in the Python REPL by putting a dictionary in an array
<d1b2>
<jer_emy> yep, I get that
<d1b2>
<jer_emy> i guess I was wondering what the shorthand way of doing this is
<d1b2>
<jer_emy> or is it just .append ?
<d1b2>
<bob_twinkles> the cute one liner is [ Signal(bit_depth) for _ in range(channel_count) ]
<d1b2>
<jer_emy> ah
<d1b2>
<jer_emy> thank you, that makes sense
<d1b2>
<bob_twinkles> np, you might also want to look at the Amaranth Memory and Array types, depending on what your ultimate reason for wanting a 2D array of signals is
lf has quit [Ping timeout: 260 seconds]
bl0x_ has joined #amaranth-lang
bl0x has quit [Ping timeout: 250 seconds]
<d1b2>
<OmniTechnoMancer> Hooray for list comprehensions
Degi has quit [Ping timeout: 276 seconds]
Degi has joined #amaranth-lang
<d1b2>
<jer_emy> how does one get pins in a connector? for example, my connector is defined as Connector("s7mini_dip_1.27mm", 0, "R15 T15 P16 R16 M13..."), how do I get the pin for index 3 ie P16 ?
cr1901 has quit [Read error: Connection reset by peer]
<d1b2>
<josuah_dem> fun fact: [minerva] stores layout in variables and calls Record(layout) whenever needed, [luna] creates classes that extends record such as class SPIBus(Record):
<ktemkin>
(yep; a bunch of that code predates modern convention and should be updated by their maintainers)
<d1b2>
<josuah_dem> ktemkin: could you point me the convention? That is something still new to me so not sure which is which.
<d1b2>
<josuah_dem> I know the end-goal is to move to Interfaces, but in the meantime there might be something else that's the commonplace use-case
<d1b2>
<josuah_dem> Also, I am curious to know where to look to pick a convention. Insofar I grep -R multiple projects for various keywords, which helps
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 461f143 - Deploying to main from @ amaranth-lang/amaranth@a0307c343d875bdec4cb1ba2989da0df4bbbe074 🚀
<adamgreig[m]>
the gist is "use `platform.request(bla, 0, xdr=2)` (the xdr=2 is the important part), then wire up `o_clk` and `o0` and `o1` signals in that resource
<d1b2>
<jer_emy> dang, i looked through your repo and totally did not see that 😦
<adamgreig[m]>
I added it a few seconds ago so that's fair enough :P
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 8a9257f - Deploying to main from @ amaranth-lang/amaranth@5f094a23eb1af4ed75f89d1456b9b9f8f53ec1ba 🚀
<tpw_rules>
just to be sure o0 is output when clock is 0 and o1 is output when clock is 1?
<whitequark>
I would strongly suggest testing this with a scope, we historically had a few cases of swapped phases
<tpw_rules>
is that something in amaranth itself or the platform library?
<tpw_rules>
(alternately asked, were those cases target-specific)
<tpw_rules>
because i had some vague memory of it being swapped too...
<whitequark>
target-specific
<tpw_rules>
that's deeply unfortunate
<whitequark>
there's no way around it, besides a process for testing and documenting
<whitequark>
that's something I'll do later this year as well
<tpw_rules>
so to be slightly less sure, is amaranth's intention that o0 is output when clock is 0 and o1 is output when clock is 1??
<tpw_rules>
(and for higher gearings that for N < M, oN is output before oM and that o0 is output when the clock is 0)
<whitequark>
o0 is the posedge and o1 is the negedge in the iCE40 platform
<tpw_rules>
so it was reversed there
<whitequark>
so, o0 is output when the clock is high, and o1 is output when the clock is low
<tpw_rules>
i knew it... is that the expected standard then or has that simply not been assigned?
<tpw_rules>
i think the iCE40 way probably makes more sense
<whitequark>
the idea here is that a clock period is divided into several equally long phases, 0, 1, ..., n for 1:(n+1) gearing, where o[0] is output during phase 0, o[1] during phase 1, and so on
<tpw_rules>
yes. then the question is is a clock period started by a posedge or a negedge
<whitequark>
so if your clock is active at posedge and has a 50% duty, it follows that for 1:2 gearing, phase 0 starts at the posedge and continues until negedeg
<tpw_rules>
ok. does amaranth track the active edge? isn't it always posedge?
<whitequark>
it does and you can have negedge triggered clock domains, but (i am sorry) right now the platform pin stuff doesn't care about it and always assumes posedge
<whitequark>
it needs a redesign either way
<whitequark>
if it bothers you, which it seems like it does, I think using the platform primitives directly is a good option
<tpw_rules>
i don't think i have a preference for either way i just don't have a good way to remember it and it's not really documented afaik
<whitequark>
yeah, it's not
<whitequark>
it's one of the worse corners of Amaranth
<tpw_rules>
i wonder if it could become .oa, .ob, .oc, .od, etc
<tpw_rules>
just a random suggestion
<whitequark>
potentially
<whitequark>
we can consider that during the redesign
<tpw_rules>
does an xdr=2 pin actually have a len(2) o in addition to o0 and o1?
<adamgreig[m]>
the confusing thing is that the returned object has len(3) or so, containing o0 and o1 and oclk, iirc
<adamgreig[m]>
you shouldn't use the top level object really
<tpw_rules>
yeah
<adamgreig[m]>
but it "works" on plain single-bit outputs, so i've seen people get in trouble when they start using xdr and it goes wrong
<adamgreig[m]>
hm, that's annoying, latest poetry version fails to include an amaranth dependency, when older poetry worked fine
<adamgreig[m]>
error in amaranth setup command: 'extras_require' must be a dictionary whose values are strings or lists of strings containing valid project/version requirement specifiers. but... the amaranth repo doesn't say extras_require anywhere
<adamgreig[m]>
python packaging 🙃
<adamgreig[m]>
outdated lockfile 🙃
<adamgreig[m]>
Catherine: looks like amaranth main depends on setuptools_scm but it's not in pyproject.toml, would you like a pr to add it / any particular version spec? latest version is 7.1.0
<whitequark>
oh, did I miss it somehow during the migration?
<whitequark>
no, pretty sure it's in pyproject.toml