02:26 <_whitenotifier-a> [amaranth] whitequark commented on issue #1628: Reduce time in combinational cycle check by skipping duplicated checks - https://github.com/amaranth-lang/amaranth/issues/1628#issuecomment-3272969425

12:57 <greghashtag9468[> I'm trying to compile down an amaranth block into verilog to include in another project. I've been using amaranth.back.verilog.convert(). This has worked well until I wanted to use io.DDRBuffer's in my design, I only end up with signal-ended signals in the final verilog.

13:00 <greghashtag9468[> Ideally I'd like to end up with {i[1:0], o[1:0], oe[0:0} as signals passed to the top level of the verilog. Would the best approach be to implement a custom `io.SimulationPort` that carries the pos/neg edge signals? Or avoid verilog.convert() and implement a custom Platform instead?

13:57 <vegard_e[m]> this sounds like a use case covered by RFC #78: https://github.com/wanda-phi/rfcs/blob/internal-port/text/0078-internal-port.md

13:57 <vegard_e[m]> oh, no

13:57 <vegard_e[m]> this is a use case that'll explicitly not be covered by RFC #78: https://github.com/amaranth-lang/rfcs/pull/78#iss

13:57 <vegard_e[m]> s/iss/issuecomment-2956517679/

13:58 <whitequark[cis]> greg.hashtag.9468: what do you want to get out of using `io.DDRBuffer`?

14:01 <greghashtag9468[> I'm specifically using the QSPI module from glasgow, which makes use of the IOStreamer class, and embeds the io.DDRBuffer class. I've attached this to Luna to implement a bootloader. This works when everything is in Amaranth.

14:03 <greghashtag9468[> I'm trying to take the same base Amaranth code, and create a verilog instance with USB/QSPI connections at the top level to drop into a LiteX project to provide a runtime bootloader function.

14:05 <vegard_e[m]> you could do a glue platform that provides a DDRBuffer platform that ties into litex

14:07 <vegard_e[m]> I've done it before, but this is pre-lib.io and not updated to current amaranth: https://github.com/zyp/zyp-amaranth-libs/blob/main/zyp_amaranth_libs/litex_glue/platform.py

14:08 <vegard_e[m]> s/platform/implementation/

14:14 <RobTaylor[m]> <vegard_e[m]> you could do a glue platform that provides a DDRBuffer platform that ties into litex

14:14 <RobTaylor[m]> ah nice!

14:14 <greghashtag9468[> I think I only need the DDRBuffer Signature aspect, since I'll need to create the actual io logic in my overarching design. Following what's been done for `SimulatableDDRBuffer` in glasgows `IOStreamer` I've created a PortLike which just connects i/o/oe through to self._port. Then created a SimulationPort with o/i widths * 2.

14:23 <greghashtag9468[> @zyp The glue/proxy platform looks like it would be a cleaner solution.

15:13 <whitequark[cis]> greg.hashtag.9468: yes, I would recommend making your own platform that instantiates the ECP5 (I assume that's what you want) DDR buffers