Add support for Colorlight i5 r7.0 with extension board

[k-haze-nil]

There is already pull request for Colorlight i5 board #148
it has only sodimm and everything else is needed to be build on top of that.
But Colorlight i5 often comes with extension board with support of hdmi and handy organisation of pins for PMOD support.

Idk if adding support for board and board with extension board simultaneously is the right way. Probably not.

[BrettRD]

pmod_3 pin 4 should be "A3" not "A12"

[BrettRD]

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.

[DaveBerkeley]

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

[BrettRD]

@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.

[DaveBerkeley]

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?

[BrettRD]

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.

[DaveBerkeley]

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

[BrettRD]

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"

[Gracana]

I think these should be swapped, like "P17 R18 C18 U16 - - M17 R17 T18 K18 - -". The PMOD standard mirrors pin numbering between the device and host side, so PMOD pin 1 on the host side is the inboard pin.

[Gracana]

Oh... the reason for the confusion is that the Muse Labs PMODs aren't built to spec. At least the 8 LED module I tested isn't. So, as written right now it'll work with Muse Labs PMODs, but to work with PMODs with properly mirrored connector layouts, the pin ordering I suggested earlier is required.