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

Support for non integer connector / ressource 'numbers' #311

Closed
anuejn opened this issue Jan 23, 2020 · 2 comments
Closed

Support for non integer connector / ressource 'numbers' #311

anuejn opened this issue Jan 23, 2020 · 2 comments
Labels

Comments

@anuejn
Copy link
Contributor

anuejn commented Jan 23, 2020

Currently nmigen.plat allows using integers to differentiate between different connectors/resources of the same type. In a design for which am writing a platform for, those are differentiated with cardinal points ("n", "s", "e", "w") , which is quite helpful in this case. Therefore I would like to do this also in the board descriptions.

What do you think about allowing strings as connector numbers, since sometimes they are more descriptive than numbers?

@whitequark
Copy link
Contributor

The idea behind using numbers is that they are, well, sequential. In Migen, platform.request would pick the next lowest number. In nMigen, this is no longer the case (because getting different resources depending on the order in which you instantiate gateware is virtually always undesirable, if your gateware is composed of nested blocks, some of which require the same resource name).

There is still however some nMigen gateware that uses this sequential property: the built-in blinky. (I assume there could be user-developed gateware that e.g. enumerates SPI ports and creates a peripheral per port, too). I think this is sufficiently useful that we should in general keep doing that. Further, fortunately, even if you have e.g. "west" button, you can also have a "0th" button; you'll just be able to request it through one alias alone.

Therefore I think we can do this.

@whitequark
Copy link
Contributor

whitequark commented Jan 31, 2020

Fixed in my fork.

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

2 participants