<sporniket>
hello, I am trying to write a component, however with components, it seems to me that the width of signals in the signature are fixed for all the same instances of the class, when I want to allow to choose at instanciation time
<sporniket>
(typically, the data width..
<sporniket>
e.g. sometime I want 8bits, other times 16, and maybe someday any value)
whitequark[cis] has joined #amaranth-lang
<whitequark[cis]>
you can define @property def signature(self): which then lets you query arguments you set in the constructor
<whitequark[cis]>
make sure to set the fields used in that property implementation before you run super().__init__
galibert[m] has joined #amaranth-lang
<galibert[m]>
sporniket: alternatively check how Arbiter does it in amaranth-soc
<galibert[m]>
It dynamically builds the signature in the constructor
<sporniket>
ok whitequark[cis], galibert[m].
<whitequark[cis]>
yeah, either option works; I recommend using @property because that means each call returns a fresh Signature object, but in some cases (like in amaranth-soc) that's actually undesirable and then that is the right approach
<whitequark[cis]>
(Signature objects are generally mutable since that enables otherwise impossible code patterns, even if it can potentially create difficult-to-find bugs; so my default recommendation is to go with the route that creates a new object each time, to make the bugs more obvious)
<sporniket>
I see. One last question, should I call super().signature too ?
<whitequark[cis]>
nope
<whitequark[cis]>
just completely override it
<galibert[m]>
Unless you derive from your own stuff super() is not going to have a non-empty signature anyway, right?
<whitequark[cis]>
yeah, it would raise an exception
<nelgau>
I understand why i{} has Flow.In, and why o{} has Flow.Out, but shouldn’t oe have Flow.Out as well?
<nelgau>
I may be missing something...
<nelgau>
Or at least I was expecting o and oe to have identical flow
<whitequark[cis]>
oh, that's a bug.
<whitequark[cis]>
could you open a PR please?
<nelgau>
Certainly
<whitequark[cis]>
ideally lib.io would be deprecated wholesale, but this is a temporary compatibility measure to get existing code to work & still be able to use interfaces
cr1901 has quit [Read error: Connection reset by peer]
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 9fd645a - Deploying to main from @ amaranth-lang/amaranth@bc316b41a89ba32570a1384c5af8fab4f5a643cc 🚀
<Wanda[cis]>
oh lol. still a CI failure, because sphinx somehow depends on a deprecated stdlib module that got nuked in 3.13
<Wanda[cis]>
Could not import extension sphinx.builders.epub3 (exception: No module named 'imghdr') ... well
<Wanda[cis]>
why... why is this getting imported anyway
<Wanda[cis]>
hm, it's fixed in the current version of sphinx
<Wanda[cis]>
apparently the doctest runner is based on epub for some reason? wtf
<whitequark[cis]>
insane
<whitequark[cis]>
we can just upgrade sphinx then
<whitequark[cis]>
can you do the needful, please?
<_whitenotifier-f>
[amaranth] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-940-bc316b41a89ba32570a1384c5af8fab4f5a643cc - https://github.com/amaranth-lang/amaranth
<Wanda[cis]>
whitequark[cis]: sure; should I just bump it to the newest?
<whitequark[cis]>
yep! go through the docs to check if it doesn't horribly misrender somehow and that's it
<Wanda[cis]>
right
<whitequark[cis]>
PSA: the next Monday meeting will be conducted at 1700 UTC, as before. (I wasn't present on the previous one because a flareup of fibromyalgia left me essentially bedridden.)
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 9f17b79 - Deploying to main from @ amaranth-lang/amaranth@1159e52921c6cbc79af1afe1304dd795f6039c9e 🚀
<coltonp>
I'm hitting this https://github.com/amaranth-lang/amaranth/issues/844 issue when following the setup instructions. Not 100% sure I understand the fix as I have libffi installed and can import cffi & ctypes without error. I'm trying in an venv (on Arch) if that matters
<whitequark[cis]>
I'm not sure if those are actually related
<whitequark[cis]>
can you show me your terminal output?
<coltonp>
Traceback (most recent call last):
<coltonp>
File "/tmp/amaranth_test/UpCounter.py", line 67, in <module>
<coltonp>
with sim.write_vcd("UpCounter.vcd"):
<coltonp>
File "/usr/lib/python3.11/contextlib.py", line 137, in __enter__
<coltonp>
return next(self.gen)
<coltonp>
^^^^^^^^^^^^^^
<coltonp>
File "/tmp/amaranth_test/env/lib/python3.11/site-packages/amaranth/sim/pysim.py", line 329, in write_vcd
<coltonp>
vcd_writer = _VCDWriter(self._fragment,
<coltonp>
^^^^^^^^^^^^^^^^^^^^^^^^^^
<coltonp>
File "/tmp/amaranth_test/env/lib/python3.11/site-packages/amaranth/sim/pysim.py", line 94, in __init__
<coltonp>
if re.search(r"[ \t\r\n]", var_name):
<coltonp>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<coltonp>
File "/usr/lib/python3.11/re/__init__.py", line 176, in search
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] a455eee - Deploying to main from @ amaranth-lang/amaranth@7e254b8657e0fa227c1b33437b6103544ca9525d 🚀
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 191070c - Deploying to main from @ amaranth-lang/amaranth@dacbd9dfb05c5250ab53945fe846b893db706e1f 🚀
coltonp has quit [Ping timeout: 248 seconds]
cr1901_ is now known as cr1901
jfng[m] has joined #amaranth-lang
<jfng[m]>
no SoC meeting today, as our agenda is still empty for now... an RFC for component metadata will come soon-ish, but i'm prototyping it first
<Wanda[cis]>
Catherine: wrt RFC 20 (non-FWFT FIFO deprecation): shouldn't constructing a `FIFOInterface(fwft=false)` also raise a deprecation warning? this is currently not included in the RFC
<Wanda[cis]>
also: any preferences on the new SyncFIFOBuffered implementation? I'm thinking of just inlining the current SyncFIFO(fwft=False) implementation directly into its code
<Wanda[cis]>
s/false/False/
mindw0rk has quit [Ping timeout: 260 seconds]
mindw0rk has joined #amaranth-lang
<Wanda[cis]>
huh, handling of edge-case-sized FIFOs is ... not ideal
<Wanda[cis]>
SyncFIFOBuffered of depth 1 will just silently fail to work
notgull has quit [Ping timeout: 245 seconds]
notgull has joined #amaranth-lang
<eigenform>
I was reading through RFC#2: is 'Signature' eventually going to turn into a generic "aggregate for Signal", regardless of whether or not they're supposed to be ports?
<galibert[m]>
You have Struct too
<galibert[m]>
Check lib.data
<galibert[m]>
Struct and Signature is the result of splitting (and enhancing) the two collided capabilities of Record
<eigenform>
My understanding is that Struct and StructLayout are about splitting a single Signal into parts, but there's still just one underlying storage location?
<galibert[m]>
And you don’t usually need to look under the cover of the struct
<eigenform>
Right, but there are other cases you might want to represent something in terms of "aggregate of Signals internal to the module" instead of flattening them into one
<eigenform>
Signature is pretty close to that (but right now it's just for describing an Interface, not some "internal" bundle of Signal)
zyp[m] has joined #amaranth-lang
<zyp[m]>
the way I see it, the main difference between a struct and an interface is that an interface is a collection of signals that each has a direction, while structs are directionless
<zyp[m]>
if you build e.g. a stream interface, you'd have signature members for payload/valid/ready/etc…, and then the payload itself could be a struct
<zyp[m]>
so first you bundle the data members together into a struct, and then you bundle that together with control signals into an interface
<eigenform>
right, but when you want to look at waveforms, the payload is flattened into a single signal - can't distinguish between struct members