There are currently two problems with amaranth-boards CI/tests:

• They are useless (i.e. don't find actual issues);
• They are broken (i.e. don't pass when there is no issue).

There is currently one problem with nmigen-boards releases:

• They aren't.

The plan I have for amaranth-boards is to release every commit (that passes checks) on PyPI. There's simply no other option besides giving up and asking downstream to use git-dependencies:

• The boards are almost all independent, but it would be wildly impractical to have a PyPI package per board.
• Both individual boards and nmigen-boards as a whole lack anything remotely close to the concept of a "release".
• Changes to existing boards should be released as soon as practical because they are either bugfixes (very important!) or additions of missing resources (pretty important too).

Technically, doing this is easy. But there are two issues that arise as a result.

1. What should be amaranth-boards' version number?
2. What version of amaranth should amaranth-boards depend on?

The first question is easy to answer. Since all of the boards are shipped together (and with resources, too), any breaking change to any board or any resource means bumping the major version. We'll end up with a major version in the hundreds very quickly, but that's OK. This allows us to do sweeping changes (like extracting resources) when necessary, and still have a version number that is more useful than a git hash.

The second question is more tricky. Since every commit to amaranth-boards becomes a release, it means that amaranth-boards should, at worst, depend on the latest released version of nmigen. But this means that, naively, adding a new platform to amaranth or changing a corner case of an existing one (something to do with oscillator instances for example) requires an amaranth release, since otherwise amaranth-boards would be broken (like it currently is). This is obviously impractical.

I propose a novel solution that I will call "fine-grained dependencies". Most of the boards in amaranth-boards are completely static (as they should be: the schematic is fixed, and the resources should not be changed on a whim) and so they only depend on old features. But some boards, particularly recent additions, will change a lot or require extremely recent features. Such boards should call some kind of function (or use any other mechanism) that would request the nMigen version through importlib_metadata and raise an ImportError if nMigen is too old.

This serves a twofold purpose:

• Downstream users get a nice error message explaining why the board file can't be used, instead of an opaque crash that looks like a bug.
• Our CI gains a way to ignore these boards when testing against latest nmigen release, yet ensure they pass tests when testing against latest nmigen snapshot.

We also should actually thoroughly test the boards and not just check that they import without errors, using some or all of the following strategies:

1. Make sure that boards with LEDs can translate blinky to Verilog.
2. Make sure that boards with LEDs and FOSS toolchains can compile blinky to bitstream.
3. Make sure that every board uses only non-overlapping pins in resources. This will probably require some heuristics and/or DSL improvements to account for alternate resource variants--think spi_flash vs spi_flash_2x. "Pin overlap is OK if there is a shared name prefix and an identical number" seems promising.
4. Make sure that every board with a FOSS toolchain uses only pins that exist.
5. The same as (3) and (4) but taking connectors into account.