I don't have particular comments except that the ARTIQ use cases (e.g. Kasli/Metlino+EEMs) should be covered, perhaps with different code.
What is inconvenient with the existing system?

What is inconvenient with the existing system?

Here's an older example of a snag w/ the existing system:

This PR is noninvasive, but I did run into an issue wrt constraints: Baseboard has a PMOD connector, and normally in Migen I see this provided as a connector with a user needs to modify w/ add_extension. In the case of Mercury, whose GPIO pins can be used standalone or with the Baseboard, the PMOD connector overlaps with the GPIO connector, and Migen is unable to detect a pin/resource conflict if I attempt to use both buses (via add_extension) at the same time. Of course, the backend will error out when trying to synthesize the design, but is this error considered acceptable?

Migen does not gracefully handle connector conflicts w/ overlapped resources, and I think perhaps it should error ASAP rather than relying on the backend to error out.

Overlapping resources should still be supported:

re overlapping resources. that's fine. we do the same with spi flash in different configurations.

That's a general issue with the current system and not specific to connectors - it never checks if a physical pin is used multiple times (the synthesis toolchain normally produces a clear error message in that case, so I didn't consider this important).

There are many other somewhat similar errors that we don't check, and they can be vendor-specific, e.g. conflicting voltages in the same I/O bank...

What is inconvenient with the existing system?

I was under assumption that the existing system does not allow using dictionaries for connectors. But of course I am wrong. So, I think no major changes are needed to the connector system specifically.

I notice that the platform code has been stubbed; removing quite a lot of complexity.

I have been testing and I have just managed to get a uart going on nmigen using a port of @whitequark 's original blog post. https://github.com/zignig/tinybx_stuff/tree/master/platform_test . Max speed is 57600 before it stops responding as echo from a 16MHz clock.

Observations:

• When requesting a Resource all the pins get assigned, not just the ones that get bound later on. having a 'gpio' resource just blocked all the available pins.

• Extending a platform and adding external interfaces should be simple

class MyCoolBoard(TinyFPGABXPlatform):
    def extend(self):
        self.add_resources([
            Resource("serial",0,
                Subsignal("tx", Pins("B8", dir="o")),
                Subsignal("rx", Pins("A8", dir="i")),
        ),
        ])

where extend is an empty function that runs straight after __init__.

Anyway, I'm going to try and hook up a Boneless to the uart tonight.