<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark b573c50 - Deploying to main from @ amaranth-lang/amaranth@656db317d221639db5d4c9e368c9c839119b291c 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 9e2c251 - Deploying to main from @ amaranth-lang/amaranth@a6e33abc5fe8973e845557d5ad239aaab123e629 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 01bf96f - Deploying to main from @ amaranth-lang/amaranth@fcbc8bd46fe291365f628a9993149c9eb8352e4f 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark b1af392 - Deploying to main from @ amaranth-lang/amaranth@c7984463c741da91c2c3074268117e9c69463af7 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 2a78703 - Deploying to main from @ amaranth-lang/amaranth@3180a17fd9283b059187cd1d259b16956545c7e3 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark d7bc953 - Deploying to main from @ amaranth-lang/amaranth@1d5e09058072fbf952b44ab77815d6b02d9a0965 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark a4284ec - Deploying to main from @ amaranth-lang/amaranth@46433268cdeed6509c1963884ce8c115ad010bcd 🚀
<FL4SHK>
thoughts on stuff like arrays of interfaces?
<galibert[m]>
what do you mean, if it's not a python array of interface objects?
<FL4SHK>
galibert[m]: my thoughts are that it should use a Python `list` of interface objects internally
<FL4SHK>
but you may want to stick such an array of interface objects into another interface object
<whitequark>
hm, this isn't something I've thought about, but it should be reasonably easy to support with our Member approach
<galibert[m]>
My question is why it should not be a python list of interface objects period?
<galibert[m]>
ahhh
<whitequark>
e.g. In[OtherInterface][4] or even In[OtherInterface[4]], and then when instantiated, yes, it will be just a list
<FL4SHK>
that sounds great
<FL4SHK>
stuff like custom interconnects are probably the main use case for this kind of thing
<galibert[m]>
I'd put the [4] inside and have the same thing on Structs
<whitequark>
I think we already have getitem defined on Layout
<whitequark>
which is why we can't have it on StructLayout
<FL4SHK>
oh
<whitequark>
we could define .array(4), maybe
<FL4SHK>
yeah, that works
<galibert[m]>
is the Layout getitem defined on numbers? Otherwise StructItem can handle it in number, pass it up otherwise
<whitequark>
it's not quite the same problem because an array of structs is a special entity since it has to use Array internally
<galibert[m]>
inheritance for the win
<whitequark>
galibert: yes it's defined
<galibert[m]>
ah, ambiguous semantics then
<whitequark>
yes
<whitequark>
(continuing on arrays) but an array of interfaces is a list of independent entities, basically
<whitequark>
galibert: oh, what we can define on structs is `*`
<whitequark>
so you would have `StructLayout({"a": 1}) * 4` and that returns an Array
<galibert[m]>
My fee feeling (usual caveat, that's my feeling only) is that Signature and Layout(? I'm lost in the names) should essentially be identical for the user except for In[]/Out[]
<galibert[m]>
* My feeling (usual caveat, that's my feeling only) is that Signature and Layout(? I'm lost in the names) should essentially be identical for the user except for In[]/Out[]
<whitequark>
Signature and Layout yeah
<whitequark>
they are not exactly identical by necessity
<whitequark>
they are similar though
<galibert[m]>
where do they diverge, outside of in/out which is the fundamental difference?
<whitequark>
there are no unions for interfaces (it makes no sense) and array semantics is rather different
<galibert[m]>
Hmmm, no unions for interfaces?
<whitequark>
nope
<whitequark>
it doesn't make sense
<galibert[m]>
Really?
<whitequark>
unions only work if you have a single underlying signal with a single direction
<whitequark>
because there are no inout signals
<galibert[m]>
ok, a union of signatures makes no sense, but a signature over an union does
<FL4SHK>
Is there any easy way, for the sake of debugging with the Verilog output, to see the *names* of the individual members of a `Struct`?
<whitequark>
then you include a UnionLayout in a Signature which is the same as using any other shape-castable
<whitequark>
FL4SHK: in the Verilog? not currently, no
<whitequark>
there is an open issue for it
<FL4SHK>
whitequark: the best I can figure is to do something with `Layout.of(my_struct)`
<whitequark>
yes, this is currently the best option
<whitequark>
this will be fixed before release
<FL4SHK>
very nice
<FL4SHK>
sounds good
<FL4SHK>
I suppose at that point I can get rid of my `Splitrec` class
<FL4SHK>
though... that one does allow a different driver for every member
<FL4SHK>
because it's not a `ValueCastable` any more
<whitequark>
that would be an interface
<FL4SHK>
the only real reason to use *that* is for the situation that interface objects solve
<FL4SHK>
yeah
<FL4SHK>
so I'll just retire my `Splitrec` once everything is built into Amaranth, like I did with my `Packrec`, which itself is fully replaced now with `View` and friends
<whitequark>
yep
<galibert[m]>
heh, good concepts should go into the main language (or libs, same difference)
<FL4SHK>
I completely agree
<whitequark>
you basically reinvented (or i guess pre-invented) interfaces and aggregates. which is fine! the development has been slow
<FL4SHK>
yeah, sorry, I've been impatient, haha
<whitequark>
that's totally okay!
<FL4SHK>
thanks
<FL4SHK>
well, I've got to get back to work
<FL4SHK>
gotta drive to the office... one of the last times I'll have to do that every week
<FL4SHK>
because I'm changing jobs to a fully remote position on Friday
<galibert[m]>
about resets, we have async resets and sync resets which are (on clk edge + enable + sync_reset force value), right? That's it, and there's nothing more needed?
<galibert[m]>
(thinking on extending the domains rfc to cover reset so that we have something complete to interate on)
<galibert[m]>
if you have a domain with a clock, a sync domain and an enable on the clock (through EnableInserter for now), reset only happens on clock edge when enable is 1, right?
<galibert[m]>
s/domain/reset/
<whitequark>
nope
<whitequark>
we have reset-over-enable
<galibert[m]>
ah
<whitequark>
so both async and sync reset behave in a similar way
<whitequark>
'reset means reset' is the principle here
<whitequark>
though... the more I think about why we want enables, I'm wondering if maybe we should have enable-over-reset
<galibert[m]>
yeah, the clock "leaking through" is not good :/
<whitequark>
if we say that logically, enables are specifically for power gating and clock division, then it would be enable-over-reset...
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 3fc80fb - Deploying to main from @ amaranth-lang/amaranth@20db537162896fb9a7c0e04b3adc542083b2994b 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark ff22679 - Deploying to main from @ amaranth-lang/amaranth@3d3846e9964e3e443fdc94cf52fdf9b77762859e 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark ce16bbf - Deploying to main from @ amaranth-lang/amaranth@1b0fb1afbcee2803152faa2fcfb1616a78ee5ea7 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark b0ac085 - Deploying to main from @ amaranth-lang/amaranth@51391be1ae2fdb115ad44f80de871a2150cb9eeb 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 9b6e075 - Deploying to main from @ amaranth-lang/amaranth@b1cce87630e917dfe09546cd78c73c7a310c6b97 🚀