<anuejn>
whitequark[cis]: after a night of sleep and your argumentation I agree, that it is probably best to close #1010
<anuejn>
the extract functionality is already there with do_build=False and I dont really know if having docker specific code in amaranth adds a lot of value vs having it downstream
<whitequark[cis]>
anuejn: I'm actually happy to have it as a shortcut
<whitequark[cis]>
and the extract being separated out is nice
<whitequark[cis]>
what I think isn't the best thing to have in Amaranth is all the customization
<anuejn>
okay
<anuejn>
I would like to keep the docker_args thing then (because otherwise the functionality is of no use to me) but I am fine with dropping all the other stuff
<whitequark[cis]>
sgtm. just make sure the doc is correct
<anuejn>
for me its --mount type=bind,source=/Users/anuejn/data/vivado-on-silicon-mac-main,target=/home/user --platform linux/amd64
<whitequark[cis]>
right, yeah, sounds good to have that
zyp[m] has joined #amaranth-lang
<zyp[m]>
how does vivado-on-silicon-mac perform? I'm curious whether I should try that next time I work with a xilinx part, or set up remote build on a linux box with older hardware
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 5347a29 - Deploying to main from @ amaranth-lang/amaranth@5d9ad62f368d28122cd0ddc6b7fb459da6d180d8 🚀
<anuejn>
I have another completely unrelated question: what is the current recommended way to have a signal with some metadata attached to it
<whitequark[cis]>
metadata for what purpose?
<anuejn>
Registers in an SoC (adresses, readable, writable)
<anuejn>
I am trying to port old code that used UserValue to the new ValueCastable but want to avoid having to type out all the __ methods from Value and forward it
<whitequark[cis]>
none (this is not done by attaching metadata to signals); use amaranth-soc whenever that gets merged
<anuejn>
hm... okay
<anuejn>
I see that it is not very nice from a design perspective but provided very nice ergonomics for prototyping stuff
<anuejn>
and it has different tradeoffs than amaranth-soc
<anuejn>
I remember there was a discussion about ila functionality needing something similiar and wanted to ask if that went anywhere yet
<whitequark[cis]>
at the time I do not plan on enabling the prototyping use case you're talking about here; I would like that effort to go towards making amaranth-soc more ergonomic rather than being split
<anuejn>
okay, thats reasonable :)
<whitequark[cis]>
for the ILA, I don't expect there to be dedicated metadata, but rather a way to query the signal hierarchy
<zignig>
hey Catherine, was cleaning up my workshop and found my tinybx again, was a bit dusty :)
<zignig>
nice work with the 0.4 release I like the component model and the wasm runners save heaps of pain.
<zignig>
I'm sorry to say that I stopped my boneless investigations and I have converted to riscv. There are a number of CPU's to choose from written in Amaranth. very cool.
<anuejn>
should I be able to index an Array with a ValueCastable directly?
<anuejn>
from the docs it seems like it ("An object deriving from :class:`ValueCastable`` is automatically converted to a :class:`Value`
<anuejn>
when it is used in a context where a :class:`Value`` is expected")
<anuejn>
but that is not the case
<anuejn>
is that a bug or am i understanding it wrong?
<whitequark[cis]>
I think that's a missing Value.cast()
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 4897cab - Deploying to main from @ amaranth-lang/amaranth@cc9fe8904983ea1226a2615e8f185fad43bfb719 🚀
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 4d0246d - Deploying to main from @ amaranth-lang/amaranth@c00e770f01262d266cd94bbb32a7b891c6a53f65 🚀
<zyp[m]>
<anuejn> "zyp: another performance figure:..." <- hmm, I don't have a good idea of how long vivado usually takes
<zyp[m]>
my last ecp5 build took 1m30s on a M2 Max, for a design that's 16.9k LUT, 7.9k FF, but AIUI the open tools are usually faster than vivado on comparable designs even when both run natively on linux