Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a library of connector layouts, too #79

Closed
whitequark opened this issue Jun 3, 2019 · 9 comments
Closed

Add a library of connector layouts, too #79

whitequark opened this issue Jun 3, 2019 · 9 comments
Labels
Milestone

Comments

@whitequark
Copy link
Contributor

whitequark commented Jun 3, 2019

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

@sbourdeauducq
Copy link
Member

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?)

@whitequark
Copy link
Contributor Author

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.

@whitequark
Copy link
Contributor Author

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.

@mithro
Copy link

mithro commented Jun 3, 2019

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.

@whitequark
Copy link
Contributor Author

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

@mithro
Copy link

mithro commented Jun 3, 2019

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

@whitequark
Copy link
Contributor Author

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.

@mithro
Copy link

mithro commented Jun 3, 2019

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

@mithro
Copy link

mithro commented Jun 3, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants