Thanks for the platform file! this saved me a lot of time.
I think the convention is moving towards inheriting from the sodimm and declaring the mapping from sodimm to pmod.
I don't know how you inherit from the i5, i9, and ice_sugar though.

I have a colorlight_i9 platform file. My PMOD connectors are wired with the rows reversed to this one. Have I got them the wrong way round?

Should I change my file to inherit or share this file? So there is a colorlight_ix.py definition, which can be passed the i5 / i9 etc?

https://github.com/DaveBerkeley/amaranth-boards/blob/colorlight_i9/amaranth_boards/colorlight_i9_r7_2.py

@DaveBerkeley I think you're right, pin1 is the one further from the edge.
https://digilent.com/reference/_media/reference/pmod/pmod-interface-specification-1_3_1.pdf

There are other expansion boards waiting for a sane design pattern before the maintainer is willing to merge them
I'd love to see this expansion board use inheritance because I have three different cards to load into it.

There are other expansion boards waiting for a sane design pattern before the maintainer is willing to merge them I'd love to see this expansion board use inheritance because I have three different cards to load into it.

Should there be a separate class for the board (with its SODIMM connector) and a wrapper class that connects the FPGA board to the expansion board? I'm now sure how best to do this. Is there a way of using connect() to do this?

I was planning on inheriting from here #148 and defining everything on the sodimm

    connectors += [
        Connector("pmod", 0, {
            "1":"63",
            "2":"59",
            "3":"51",
            "4":"81",
            "7":"65",
            "8":"61",
            "9":"57",
            "10":"49",
        }, conn=("ddr2-sodimm-200p",0)),

        Connector("pmod", 1, {
            "1":"89",
            "2":"83",
            "3":"79",
            "4":"75",
            "7":"95",
            "8":"85",
            "9":"81",
            "10":"77",
        }, conn=("ddr2-sodimm-200p",0)),

        ...

    ])

The platform inherits from the LatticeECP5Platform class, that gets changed to ColorLightI9Platform or ColorLightI5Platform but I don't know how to tell the class to inherit from only one.

That looks like a good approach. It reflects the physical wiring.

For litex-boards I added a board="i9" parameter to the platform and target files. Then took a deep copy of the config, modifying it (slightly) for the i9. So there is just one Colorlight_ix class, whose structure is defined by args.

So a base class for the module, with eg ctor(board="i9", revision="7.2"), which defines everything on the module, can then be placed in the expansion board (a derived class), which maps the sodimm to the pmods etc. So you could simply pass the board/revision args to the underlying base class in the expansion board class ctor. The expansion board class may not even need its own constructor. It is a just a set of mappings.

The Litex boards don't do this, but perhaps they should :

https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/colorlight_i5.py
https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/colorlight_i5.py

The expansion board really is just a collection of connectors and resources,
In the simplest case we could define the list of connectors and resources as const, then create very short sub-classes that define a new platform with the added connectors

# Describe the features of the expansion board and how they're wired
expansion_board_connectors = [...] # but in a sane namespace, or possibly a class
expansion_board_resources = [...]

# List the known compatible boards
class Colorlighti5R70ExtensionBoardPlatform(ColorLightI5Platform):
    connectors = super().connectors + expansion_board_connectors
    resources = super().resources + expansion_board_resources

class ColorLightI9ExtensionBoardPlatform(ColorLightI9Platform):
    connectors = super().connectors + expansion_board_connectors
    resources = super().resources + expansion_board_resources

class IceSugarExtensionBoardPlatform(IceSugarPlatform):
    connectors = super().connectors + expansion_board_connectors
    resources = super().resources + expansion_board_resources

That would allow Luna builds to use the platform as they always have
os.environ["LUNA_PLATFORM"] = "amaranth_boards/colorlight_i5_r7_0_ext_board:Colorlighti5R70ExtensionBoardPlatform"