For boards with FOSS toolchains it would be nice to check additional properties, like using a valid IOSTANDARD (existing and for example using a differential standard for differential pins), using non-conflicting IOSTANDARDs for pins on the same bank, and furthermore check if all the Attrs are valid.
This opens the question about how to handle boards that have multiple different configurations (like the Atlys board changing IOSTANDARDs depending on a constructor argument).

It would indeed be nice, but I think we should ship something much simpler first.

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.

I'm pretty sure this is the wrong solution, but I'm going to suggest it anyway.

You could try to import all board modules catching import errors. If a board import fails with such an import error, replace the board with a class that just generates an exception if someone actually tries to use the board....

I have seen this idea go wrong in so many different ways (which is what makes me think it is the wrong solution), but if there is actually someone who could make it work in a sane and reliably, it would probably be @whitequark...

If you are going the automated publishing to PyPi route, maybe the idea of just publishing every board into a seperate PyPi package works? That way users only depend directly on the boards they actually want to support (and thus a minimum nmigen version?).

You could also then have a nmigen-boards meta package which depends on them all for convenience or could even be more super fancy and then also have different meta package "groupings" of nmigen-boards (like nmigen-boards-vivado -- any board which works with the Vivado platform) or something....

I have seen this idea go wrong in so many different ways (which is what makes me think it is the wrong solution), but if there is actually someone who could make it work in a sane and reliably, it would probably be @whitequark...

@mithro Hooking into the board import code path is basically what I want to do, except, as you correctly note, in a sane and reliable way.

If you are going the automated publishing to PyPi route, maybe the idea of just publishing every board into a seperate PyPi package works? That way users only depend directly on the boards they actually want to support (and thus a minimum nmigen version?).

I have of course considered that, but it's a logistical nightmare: it increases the workload required to add a new board several times over, it requires some sort of complicated automatic versioning scheme (because there is no way that can be managed manually), it will annoy our users (especially those who install the full package), it will no doubt expose new and exciting edge cases in the pip dependency resolver, and so on.

Sure, the idea sounds reasonable at first glance, but... even the 4 PyPI packages nmigen is currently split into present a noticeable maintenance burden. YoWASP, which is a dozen packages, is still a greater burden even in spite of me automating every action I could script and have it run reliably. Split nmigen-boards would be nothing short of a total nightmare.

Actually, I forgot the part where I would have to manually click through checks repository 50 (and growing) PyPI packages if I ever want to add a second maintainer. PyPI doesn't have any sort of organizations or group accounts, so every time I need to do something with YoWASP on Test PyPI after it gets wiped, I get dangerously close to carpal tunnel syndrome.

I'm guessing what you are really saying is that PyPi doesn't provide a package management API so you have to do all that manually?

I'm guessing what you are really saying is that PyPi doesn't provide a package management API so you have to do all that manually?

Yes, although there is also the problem that it greatly multiplies the amount of possible package conflicts. (In particular this scheme may not be used until the entire Python ecosystem migrates to the new pip dependency resolver.)

Hello, since I finally got myself an actual FPGA dev board, a so called "Colorlight i9" with its extended board, which is not bundled yet, I was trying to do yet another one (there are some PRs though)

For this topic, I am thinking that the "amaranth-board" repository is a mix of two things :

• a specific api : ressources and extensions (that for now looks like some other ressources, i have yet to see why it is separate)
• the board definitions

I would separate them. The api part would either be an independant library, or preferably reintegrate amaranth to leverage the release.

The "amaranth_board" would then be only a bunch of definitions of boards, added and updated/fixed on demand (PRs). Since it would not be a set of features, but more a collection of COTS, I would drop any numbering scheme and use a timestamp (like '2022.09.17')

That leaves the "test" (actually just 'blinky'). I see it more like a demo code that helps to verify that the targeted resource is correctly implemented. Thus I would extends this part so that each kind of resource has a typical demo code (some are easy to devise like led and GPIO, others would be more difficult, and except the onboard leds, any other test would require some test rigs that the user would have to build and connect to the board). And then for each board, the main execution would generate each relevant demo gateware, to be uploaded by the user for verification.

I would separate them. The api part would either be an independant library, or preferably reintegrate amaranth to leverage the release.

Right now these are often updated in lockstep with the boards, which I think is important. This is essentially the "monorepo" approach to updating dependencies. It arguably doesn't scale.

That leaves the "test" (actually just 'blinky'). I see it more like a demo code that helps to verify that the targeted resource is correctly implemented. Thus I would extends this part so that each kind of resource has a typical demo code (some are easy to devise like led and GPIO, others would be more difficult, and except the onboard leds, any other test would require some test rigs that the user would have to build and connect to the board). And then for each board, the main execution would generate each relevant demo gateware, to be uploaded by the user for verification.

It would be very nice to have something like that available. Unfortunately I'm not sure if we'll ever find people who can spend the effort of maintaining such test code for a very wide array of boards.

I plan to to something for testing my board's GPIOs. A blinky parametrized with the connector name / pin name. When I have something, I will post a PR of this demo for sure.