PoC for using Amaranth's FHDL compat mode as alternative to Migen's FHDL.

[enjoy-digital]

The aim of this PoC is to enhance the flexibility of LiteX by enabling switching between Migen and Amaranth in Migen's compatibility mode, which would:

• Allow users willing to build LiteX designs to use Amaranth without requiring Migen installation.
• Reduce the need for glue scripts/logic between LiteX and Amaranth during the design and integration phases.
• Allow evaluating the effort to be done to build current complex designs with Amaranth/LiteX (complex not necessarily in term of amount of logic but in term of clock domains/design constraints: ex an SDR SoC with PCIe, DDR3 and > 10 clock domains).

The reasons/context of the current use of Migen has been described in https://github.com/enjoy-digital/litex/wiki/Migen-Amaranth and this PoC would be a first step to decouple LiteX from Migen or a specific DSL (having our own DSL or customized DSL as an alternative to Migen/Amaranth could also be interesting for some specific use-cases).

For the initial proof-of-concept (PoC), we would switch only the FHDL while continuing to use LiteX's Platform/Build system. This would already allow us to leverage Amaranth's language and benefits while high-level development of LIteX/Amaranth could continue with their own respective approaches.

Steps for Implementation:

• Relocate Migen code that is not in Amaranth's compatibility mode directly to litex.gen. This code would then directly use Amaranth's compatibility mode during the build.
• Have Amaranth's compatibility mode installed as a Migen package or refactor Migen imports in LiteX to a generic import that can be either Migen or Amaranth.
• Decouple the LiteX build system from Migen's internals. For example, when adding the keep attribute on signals, checking/getting signal names, etc. This would need to be decoupled or improved for correct code generation with Amaranth.
• Ensure Amaranth's compatibility mode supports Migen's lowering and, if not, add the code to support it.
• And probably others details... :)

Testing Approach:

We could progressively test the PoC on designs of increasing complexity:

• Minimal design: ex Led Blinker, SoCMini with UARTBone.
• Minimal SoC: ex CPU + ROM + RAM + UART.
• SoC: ex CPU + ROM + RAM + UART + Ethernet + DDR3
• etc.

[josuah]

Amaranth boards definitions come without any elaboratable logic.

That could be a relatively self-contained subset, more easily bridged to LiteX than the whole Amaranth language.