12:19 <RobTaylor[m]> <whitequark[cis]> "Rob Taylor: something that may..." <- oh cool. Might be worth you taking a look at my (wip for handling pins in chipflow-lib)[https://github.com/ChipFlow/chipflow-lib/pull/38] - all critisism gladly received =)

12:20 <RobTaylor[m]> stupid question - can you get the clock domains needed by a Fragment, or do you always need to know a-priori?

12:20 <RobTaylor[m]> * oh cool. Might be worth you taking a look at my (wip for handling pins in chipflow-lib)[https://github.com/ChipFlow/chipflow-lib/pull/38] - all criticism gladly received =)

14:04 <whitequark[cis]> Rob Taylor: i've looked at iosignatures etc and i'm really not a fan

14:05 <whitequark[cis]> re: clock domains needed by a fragment: there is no supported way to do so and any implementation using the internals is very likely to stop working once we finish clock domain rework

15:30 <RobTaylor[m]> <whitequark[cis]> "Rob Taylor: i've looked at..." <- thanks :) What do you see at the issues/drawbacks?

15:31 <RobTaylor[m]> <whitequark[cis]> "re: clock domains needed by a..." <- fair enough, wheres best to track the clock domain rework? Also any thoughts on power domains as part of that?

15:43 <RobTaylor[m]> * the issues/drawbacks? if you don't mind me asking!

15:45 <whitequark[cis]> <RobTaylor[m]> "thanks :) What do you see at the..." <- a major one is that by only passing the triple of (i,o,oe) around, you are losing the clock domain; therefore if you instantiate an FFBuffer on the edge, the domain has to be manually matched to what the peripheral wants. this is very error-prone

15:46 <whitequark[cis]> what I think I'm going to do is a special component, let's say PinMux, which accepts any type of PortLike, and provides its own PortLike on request. it will internally instantiate DDR buffers (since many of the amaranth-stdio peripherals will expect to use DDR buffers, for 2x increase in max clock frequency) and add clock muxing in addition to i/o/oe muxing

15:47 <whitequark[cis]> this will necessitate adding a glitchless clock mux component first, which I think I'll do as an RFC, since it really belongs to the Amaranth core

15:47 <whitequark[cis]> <RobTaylor[m]> "fair enough, wheres best to..." <- there is no centralized place to track clock domain rework. you can track it by following the RFCs and discussion on this channel

15:48 <whitequark[cis]> we don't have any specific plans to handle power domains as a part of that. your input on the RFC may change that

15:50 <RobTaylor[m]> whitequark[cis]: oooh, thats a really good point

15:50 <RobTaylor[m]> whitequark[cis]: nice!

15:51 <whitequark[cis]> I think the design you have for IO muxing is essentially broken architecturally, and will not scale beyond single clock domain designs

15:51 <RobTaylor[m]> whitequark[cis]: that sounds lovely :)

15:51 <RobTaylor[m]> whitequark[cis]: I'll try to give input :)

15:51 <whitequark[cis]> I really do need a proper pin mux in Glasgow (for the probe-rs applet, to be able to have either JTAG or SWD on the same pins...) so I don't mind you reusing that of course

15:52 <RobTaylor[m]> we certianly will :)

15:53 <whitequark[cis]> it will have the downside that you cannot switch from a pin with a stopped clock (when using clocked buffers) because of the way glitchless clock muxes work

15:53 <whitequark[cis]> it's also going to be an FPGA-oriented design more than an ASIC-oriented. but you will be able to keep the external interface (which is obviously what makes it feasible--or not--to reuse amaranth-stdio components) and replace the guts with a more ASIC-focused netlist

15:54 <RobTaylor[m]> RobTaylor[m]: Does adding clock domain annotation to the sig help this, or would that cause more problems do you think?

15:54 <RobTaylor[m]> A lot of this is really about port facing IPs being able to share enough metadata for the framework to assemble correctly

15:54 <whitequark[cis]> that's kind of a vague question I can't answer without more context

15:55 <RobTaylor[m]> whitequark[cis]: Will it need all clocks it is muxing to be running?

15:55 <RobTaylor[m]> whitequark[cis]: fair point. I'll give it a try and see, then i can formulate better

15:56 <whitequark[cis]> RobTaylor[m]: it will need the clock you're switching _from_ to be running (as well as the clock you're switching _to_) whenever you are doing a switch

15:56 <whitequark[cis]> the others are irrelevant

15:57 <RobTaylor[m]> whitequark[cis]: That seems like a perfectly fine requirement to me.

15:58 <whitequark[cis]> there are practical designs where it's a problem; I've encountered such designs before. but really, my job here is to highlight the limitation, not to decide whether it's acceptable or not

15:58 <whitequark[cis]> a glitchless clock mux is a very well known type of circuit so we really should have that

16:02 <RobTaylor[m]> whitequark[cis]: 100%

16:29 <RobTaylor[m]> <RobTaylor[m]> "fair point. I'll give it a try..." <- ah, i see why it currently isn't a problem, as the IPs always allocate their own buffers via platform, so there's not currently any buffer allocation downstream of an IOSignature. Of course that fails when you have a pinmux...

16:35 <whitequark[cis]> the buffer instantiation should of course be the responsibility of the IP

16:36 <whitequark[cis]> not having this functionality was one of the major failures in early amaranth versions