This should be SPIResources, I think; there's currently no way to override the name, but probably there should be!

I agree, and I was going to do this until I saw there was no name override.

Looks like you already noticed this, but just to reiterate, SPIResources does not work for spiserial because all the SPI pins are reversed by nature of FPGA being the secondary. Perhaps add something to account for this too?

We could add a dir switch to SPIResources itself, defaulting to "o".

This should use check_call instead (I fixed it recently on other boards).

This and the two following resources have wrong indentation.

I accidentally forgot to remove the check=True argument, so I fixed and forced-pushed. Just FYI.

Shouldn't this be one large group of resources called baseboard?

No, because of the way SRAM works on this board, there are times you want to selectively enable certain baseboard peripherals without enabling others. In particular, only VGA and PS/2 can be enabled while still giving you access to the SRAM.

So maybe more like baseboard_no_sram and baseboard_sram then?

That's a good compromise¹, I'll look at the schematic and see which components fit under each. To avoid repetition, I think I should keep the existing Resource arrays around, but maybe prefix with _ as "internal"?

1. Btw, just as an anecdote- even with the baseboard attachment, all of Mercury's GPIO is still broken out, so one can attach their own peripherals. In practice, I've found this to not work at all due to loading issues :P.

To avoid repetition, I think I should keep the existing Resource arrays around, but maybe prefix with _ as "internal"?

Yes, that's what I would do.

This is... really, really confusing. Just reading this comment I have absolutely no idea how to use it correctly. Perhaps this needs some rethinking?

Put another way:

The gpio_ctl Resource shouldn't exist at all. It is only useful when paired with the gpio_sram_bus Resource.

gpio_sram_bus and essentially the whole gpio connector are electrically connected, so using the SRAM implies giving up the gpio connector.

The remaining two pins provided by gpio_ctl are not broken out to any connector. omigen couldn't handle a peripheral that was only-partially broken-out to a connector. So I added that comment to let ppl know (apparently badly) that "you really can't use gpio_sram_bus without gpio_ctl and you should do plat.request for both and Cat them into a single Signal- or better yet, merge them into a single Record- after the fact.

Can nmigen handle a only-partially broken-out peripheral as a single Resource?

Can nmigen handle a only-partially broken-out peripheral as a single Resource?

The following Resource definition appears to "do the correct thing":

    gpio_sram_bus = [
        Resource("gpio_sram_bus", 0,
            Subsignal("ce", PinsN("P3", dir="o")),  # Memory chip-enable.
            # Called MEM_CEN in schematic.
            Subsignal("bussw_oe", Pins("P30N", dir="o")),  # 5V tolerant GPIO
            # is shared w/ memory using this pin.

            # Actual SRAM connections.
            Subsignal("a", Pins(""" 1  2  3  4  5  6  7  8  9 10
                                   11 12 13 14 15 16 17 18 19 20""", dir="o",
                                conn=("gpio", 0))),
            # A19 is actually unused- free for GPIO
            # 8-bit data bus
            Subsignal("d", Pins("21 22 23 24 25 26 27 28", dir="io",
                                conn=("gpio", 0))),
            Subsignal("we", PinsN("29", dir="o", conn=("gpio", 0))),
            # "Unused" is only used by GPIO, but is included here for
            # consistency.
            Subsignal("unused", Pins("30", dir="io", conn=("gpio", 0))),
            # Subsignal("oe_n", Pins()),  # If OE wasn't tied to ground on
            # Mercury, this pin would be here.
            Attrs(IOSTANDARD="LVTTL", SLEW="FAST")
        )
    ]

From playing in a REPL:

William@William-THINK MINGW64 ~/src/migen_mercury/baseboard
$ python3
Python 3.7.3 (default, Apr 23 2019, 08:20:20)  [GCC 8.3.0 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from nmigen_boards.mercury import *
>>> plat = MercuryPlatform()
>>> plat.add_resources(plat.gpio_sram_bus)
>>> sigs = plat.request("gpio_sram_bus")
>>> sigs
(rec gpio_sram_bus_0 (rec gpio_sram_bus_0__ce o) (rec gpio_sram_bus_0__bussw_oe o) (rec gpio_sram_bus_0__a o) (rec gpio_sram_bus_0__d i o oe) (rec gpio_sram_bus_0__we o) (rec gpio_sram_bus_0__unused i o oe))

From what I can gather, this works because in nmigen, adding a Resource is done the same way (plat.add_resource) regardless of whether said Resource uses connector pins or not. So it makes sense that mixing and matching Pins that resolve to connectors and Pins that resolve directly to FPGA pins works.

I wonder if this was also true in omigen and I never noticed it?

Is this necessary?

Not at all, just for testing that -opt_mode AREA works. In omigen, this was the default for this platform unconditionally.

But I've come around to the idea that in nmigen, the user should add it on a build-by-build basis.

spi_serial

spi_adc