00:06 <vegard_e[m]> theoretically it's possible to simply just add a signature to a record

00:07 <vegard_e[m]> and it should be fairly trivial to write a helper that iterates/recurses though a record layout and generates an equivalent signature

00:07 <whitequark[cis]> there isn't; you could make such a way yourself if you need it

00:08 <vegard_e[m]> only gotcha is that record instances doesn't have an overall direction, wiring interfaces does

00:08 <_whitenotifier-4> [amaranth] whitequark closed issue #1551: Amaranth not compatible with Yosys 0.48 - https://github.com/amaranth-lang/amaranth/issues/1551

00:41 <greghashtag9468[> I've been using the built-in stream support to build up a data pipelines. I have components that wrap sequences of blocks together.

00:41 <greghashtag9468[> Is there a preferred way to connect to a stream exposed as a component interface from within the module? Using `wiring.connect` picks up the wrong direction, as it sees the external Out/In direction.

00:44 <greghashtag9468[> I'm currently using a wrapper function to extract the signature of the stream and flip it, this seems a bit better than manually connecting stream members. But curious if there is a better way.

00:44 <vegard_e[m]> flipped()

00:48 <greghashtag9468[> Ahh, yep. flipped() does exactly what I need. 👍

00:50 <whitequark[cis]> hi Greg!

00:50 <whitequark[cis]> how's your experience with the wiring library so far?

00:55 <greghashtag9468[> I like it. Adding more design intent to each module/blocks interfaces is good.

01:10 <greghashtag9468[> My current project is porting a MIPI PHY I'd written in litex over to amaranth. I have noticed the simulator creates a lot of duplicate names. Each block has an "i" and "o" stream. In the simulator the module contains `o__payload`, `o__payload$20`, etc. It's a bit tricky to pair up payload/valid/ready groups. This might just be a user error. 😅

01:20 <whitequark[cis]> ah, so this isn't (just) a simulator issue, the namer is the same for RTL output

01:20 <whitequark[cis]> we have an open issue for improving the namer

01:31 <greghashtag9468[> That makes, sense. It doesn't seem like there is way yet of not creating overlaping names using `wiring.connect`. I'm using kwargs as demonstrated in the docs. If that could be prefixed to the signals connected? I've not thought through any extra implication of that.

01:36 <whitequark[cis]> the namer doesn't know you're using connect(), since connect() is just a bunch of .eq()

01:37 <whitequark[cis]> all it knows is signal names + some abstracted version of the hierarchy

01:37 <whitequark[cis]> the rest of the context is lost by that point

01:37 <whitequark[cis]> (unfortunately this is fairly normal for a compiler)