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

Per-pin direction control for platform defined IOs #413

Closed
jeanthom opened this issue Jun 25, 2020 · 6 comments
Closed

Per-pin direction control for platform defined IOs #413

jeanthom opened this issue Jun 25, 2020 · 6 comments
Labels

Comments

@jeanthom
Copy link
Contributor

In LiteDRAM, each DQ pin has its OE signal driven by its own TSHX2DQSA instance. There are currently two ways of doing this in nMigen:

  • Declare a bidirectional subsignal for each IO: nMigen takes care of the bidirectional IO initialization, but you end up with dozens of independent subsignals
  • Using dir={"mysubsignal":"-"} when platform.request is called: you have to declare the bidirectional IO instances yourself

We're not sure that we actually have to declare TSHX2DQSA for each pin, but that might be useful for other protocols (which ones?).

@whitequark
Copy link
Member

  • Using dir={"mysubsignal":"-"} when platform.request is called: you have to declare the bidirectional IO instances yourself

Can you actually do this? I recall that you ran into some trouble where the TSHX2DQSA instances had to be in the toplevel module, which isn't easily expressible in nMigen. Is that right?

@jeanthom
Copy link
Contributor Author

Yep, it turned out to be an issue in my code. It does synthesize correctly in Yosys/Nextpnr and Diamond.

@whitequark
Copy link
Member

Then I would say that using dir="-" is the proper solution here. It works and it matches LiteDRAM code; is there any reason you want to avoid it?

@jeanthom
Copy link
Contributor Author

What's bothering me is that it is generally the responsibility of the end user to write the platform.request code. Ideally you'd want the end user to deal with the least amount of platform dependant code so that their code is portable across FPGA boards or even FPGA architectures.

@whitequark
Copy link
Member

Of course. But the entire reason you are having this problem is that you are using the platform specific primitive TSHX2DQSA, right? So it makes no sense to try and abstract over this stuff if in the end you're going to break the abstraction anyway.

@whitequark
Copy link
Member

Closing in favor of #458.

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

No branches or pull requests

2 participants