Add a library of connector layouts, too

[nmigen-issue-migration]

Issue by whitequark
Monday Jun 03, 2019 at 15:05 GMT
Originally opened as m-labs/nmigen#79

---

E.g. codify this document as vendor.conn.pmod or something like that.

[nmigen-issue-migration]

Comment by sbourdeauducq
Monday Jun 03, 2019 at 15:38 GMT

---

Should we put this kind of vendor-specific library in nmigen or in a separate package?
(and what about the board definitions? where to draw the line?)

[nmigen-issue-migration]

Comment by whitequark
Monday Jun 03, 2019 at 15:44 GMT

---

I think it should live together with the board definitions. And I think board definitions should be split. nMigen then can have proper releases, and the board/connector/etc package can be built and uploaded to PyPI each time a CI build succeeds.

[nmigen-issue-migration]

Comment by whitequark
Monday Jun 03, 2019 at 15:46 GMT

---

Conversely, what we currently have as vendor.fpga should stay inside nMigen as the per-family primitives are fairly tied into the core of nMigen. E.g. the lowering for AsyncResetSynchronizer depends on the way attributes are processed and so on.

[nmigen-issue-migration]

Comment by mithro
Monday Jun 03, 2019 at 16:00 GMT

---

FYI - I long time ago I started trying to figure out the various ways pmod is used. You can find a class structure I was building at https://github.com/mithro/HDMI2USB-litex-firmware-old/blob/pmod-extra/pmod.py

I also have a spreadsheet which tracks a lot of details about how people use pmod.

[nmigen-issue-migration]

Comment by whitequark
Monday Jun 03, 2019 at 16:01 GMT

---

@mithro But that's all just copied from the pmod spec...

[nmigen-issue-migration]

Comment by mithro
Monday Jun 03, 2019 at 16:07 GMT

---

@whitequark - Yes, a lot of the data is directly from the pmod spec in a more visual / collected form that I find easier to understand. There is also a bunch of information about how people are trying to do high speed over Pmod in the later sheets (Pmod High Speed, Pmod High Speed Hosts, "Pmod Like" Expansion Boards).

[nmigen-issue-migration]

Comment by whitequark
Monday Jun 03, 2019 at 16:07 GMT

---

So I imagine a library of functions like this:

def PmodSPIResource(name, number, *, pmod, extras):
    return Resource(name, number,
        Subsignal("cs_n", Pins("0", dir="o", conn=("pmod", pmod))),
        Subsignal("clk",  Pins("1", dir="o", conn=("pmod", pmod))),
        Subsignal("mosi", Pins("2", dir="o", conn=("pmod", pmod))),
        Subsignal("miso", Pins("3", dir="i", conn=("pmod", pmod))),
        extras=extras
    )

Then it can be used:

platform.add_resources([
    PmodSPIResource("spiflash", 1, pmod=0, extras={"IO_STANDARD": "SB_LVCMOS33"})
])

There's no need for something complicated like classes.

[nmigen-issue-migration]

Comment by mithro
Monday Jun 03, 2019 at 16:11 GMT

---

@whitequark I'm not tied to the idea of classes, something like what you proposed would also work.

[nmigen-issue-migration]

Comment by mithro
Monday Jun 03, 2019 at 16:19 GMT

---

I think having a standard library with these types of things in it is the important part.