<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 48c7437 - Deploying to main from @ amaranth-lang/amaranth@9b4ad4ec5da7d87c809290ebb44bbc2bb5bdc201 🚀
<AhmedCharles[m]>
Does the Memory library support SPRAM (single port ram) on the ice40 UP?
<whitequark[cis]>
yes with recent enough yosys, i believe
<whitequark[cis]>
ah, actually, no, because amaranth requires every memory to be initialized and SPRAM can't be initialized
<AhmedCharles[m]>
So, in theory, I could use an Instance.
<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 3486911 - Deploying to main from @ amaranth-lang/amaranth@b8dc2338043c0de2938bb285068be4e6256b8cea 🚀
RobTaylor[m] has joined #amaranth-lang
<RobTaylor[m]>
stupid question - given a pureinterface, is there a way to tell what component its connected to? (pre or post elaboration)
<whitequark[cis]>
not via the public interface
<whitequark[cis]>
and, in the general case, not via the private interface either
<whitequark[cis]>
(since you could have it connected to any number of components in any number of ways)
<whitequark[cis]>
you should design your system in a way where you don't need this information, i think
<RobTaylor[m]>
makes sense
<whitequark[cis]>
or if it's unavoidable, make a custom wrapper around wiring.connect that stores it somewhere
* RobTaylor[m]
ponders some more
<RobTaylor[m]>
thank you
<RobTaylor[m]>
i guess what i'm really looking for is a way to percolate metadata from internal components down to external interfaces
<whitequark[cis]>
the way we designed the metadata system, this is something that should be done explicitly
<whitequark[cis]>
i like the explicitness: it is important to distinguish between private and public interfaces
<whitequark[cis]>
you have a wiring.connect(m, flipped(self.interface), self.internal.interface) somewhere, right? that's also a good place to propagate metadata
<RobTaylor[m]>
so you'd add after the connect a sort of set_metadata(self.interface, m.submodule.component, <data specifier>)?
<whitequark[cis]>
maybe? it's hard to say much more because i don't actually know the overall design of the system you're talking about
<whitequark[cis]>
but generally, that's the direction i'd say you should go
<RobTaylor[m]>
thank you :)
<whitequark[cis]>
the metadata system has seen very limited use so i'm not surprised if it has ergonomics issues
<RobTaylor[m]>
yeah, i'll spend some time collating the usecases i'm doing evil things for at the moment for discussion =) I think a lot can be done by enhancing the amaranth-soc metadata
<whitequark[cis]>
it's also intentionally very generic and in some ways more of a "metadata system construction toolkit" than a finished "metadata system"
<whitequark[cis]>
it's possible we should enhance wiring.connect with the ability to propagate metadata, now that you've mentioned it
<whitequark[cis]>
i'm not sure yet
<RobTaylor[m]>
it would be kinda cool. Needs some serious thought though, as you say, otherwise you could potentially get combinatoric explosion of metadata
<whitequark[cis]>
this is definitely something that i'd want to see an RFC for simply because it's not clear what the best design is
<whitequark[cis]>
what you could always do is to define Signature.annotations for your signature in a way where it checks for an attribute (eg metadata) on the interface object first
<whitequark[cis]>
then you do self.interface.metadata = self.internal.interface.signature.annotations(self.internal.interface), which is a bit of a mouthful but could be abstracted
* RobTaylor[m]
ponders
<whitequark[cis]>
the problem with "propagating" metadata on wiring.connect is that if you design it naively it is sensitive to order of connections
<whitequark[cis]>
imagine `Top -> SoC -> Periph`, you `connect(Top.bus, SoC.bus)` first, then `connect(SoC.bus, Periph.bus)`
<whitequark[cis]>
easy to get without annotations on Top.bus
<whitequark[cis]>
s/without/no/, s//`/, s//`/
<RobTaylor[m]>
yep. I suspect the things i'm trying to solve for may be better handled by having amaranth-soc metadata include component's metadata
<RobTaylor[m]>
s/component/components/
<zyp[m]>
<RobTaylor[m]> i guess what i'm really looking for is a way to percolate metadata from internal components down to external interfaces
<zyp[m]>
is this for memory mapped components, or other components?
<RobTaylor[m]>
zyp[m]: yep memory-mapped (e.g. spiflash, with csr registers and a wishbone window)
<zyp[m]>
in that case, I still think attaching additional annotations to the memory map is the way to go
<RobTaylor[m]>
maybe, though its a question of what in the memory map to attach things to (e.g. you get the registers as seperate items, there's not an entity that maps to the whole component) , and as we discussed, when to do it :/
<zyp[m]>
the memory map that lists the separate items is the entity that maps to the whole component
<zyp[m]>
s/separate/registers/, s/items//
<RobTaylor[m]>
its not really, its the bus that those registers are on
<zyp[m]>
to be specific, it's the bus port of the whole component
<RobTaylor[m]>
yep. a subtle difference that gets you when you have a component like spiflash
<RobTaylor[m]>
i'm not necessarily saying you're wrong btw, just thinking through it..
<zyp[m]>
IIRC one thought I had when I worked on katsuo-bridge was that the separation between windows and resources in the metadata isn't all that useful
<zyp[m]>
how does your spiflash component work? does it have two separate bus ports (for control registers and for memory mapped flash access/XIP)?
<whitequark[cis]>
zyp[m]: IIRC I discussed this with JF and we considered simplifying it
<whitequark[cis]>
but it never happened
<RobTaylor[m]>
zyp[m]: yep, exactly :)
<RobTaylor[m]>
<zyp[m]> IIRC one thought I had when I worked on katsuo-bridge was that the separation between windows and resources in the metadata isn't all that useful
<RobTaylor[m]>
yeah, i had the same feeling too
<zyp[m]>
right, so the component ends up appearing twice in the memory metadata tree
<zyp[m]>
the solution to that is probably to have an annotation for each, referencing each other through a common unique ID
<whitequark[cis]>
it sounds like maybe the component shouldn't be the thing that's placed in the memory metadata tree
<whitequark[cis]>
but i'm sufficiently far out of the context that i'm not sure at all
<zyp[m]>
yeah, the annotations I've been attaching to memory maps are not attached to the component itself
<RobTaylor[m]>
i'm unsure, its all a bit caught up in my head with driver configuration and things like device tree
<zyp[m]>
device trees have references :)
<RobTaylor[m]>
need to untangle. But yeah atatching a uid to metadata on the bus interfaces makes sense, as you say
<zyp[m]>
the question then is, how do we make a unique ID? I figure we probably want it to be deterministic, otherwise the easy solution would be just an UUID
<RobTaylor[m]>
i think we need to start a doc collecting usecases
<whitequark[cis]>
agreed
<whitequark[cis]>
maybe an issue/discussion on amaranth-soc repo?