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:

• [x] 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.

[josuah]

• [ ] 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.

Some practical way to try this could be to temporarily uninstall migen and try to run some build scripts. For instance on litex-boards: 1. ... --build then uninstalling migen then ... --load.

And then modifying the source until this works.

[enjoy-digital]

Hi @josuah,

the aim for now is to be able to be able to reuse Amaranth as drop in replacement for Migen's FHDL, so for logic generation. To avoid uninstalling migen, a possibility for initial tests is to do something like this in the tested scripts:

import sys
import amaranth.compat as migen
sys.modules['migen'] = migen

I started doing some tests with Migen examples with this, but then discussed with @whitequark and we agreed to let her do some initial work to refactor the compatibility layer, move it to another repo and continue the tests after this.

[josuah]

Thank you for helping me catching-up!

What I just understand now is that the goal is to switch the migen implementation rather than reduce the reliance on migen language.

This makes sense given it keeps everything that uses LiteX today working.