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

DDR pins and *_n signals #74

Closed
jeanthom opened this issue Jul 7, 2020 · 2 comments
Closed

DDR pins and *_n signals #74

jeanthom opened this issue Jul 7, 2020 · 2 comments
Labels

Comments

@jeanthom
Copy link

@jeanthom jeanthom commented Jul 7, 2020

Hi,

For some peripherals (eg. DDR memory) there are inverted pins (RAS_N, CAS_N, etc. in DDR3) that are configured as PinsN. The issue with PinsN is that it gets an inverter inserted between the TRELLIS_IO instance (on ECP5 platform) and the .o exposed to the user which prevents the use of DDR primitives (ERROR: ODDRX2F 'ddrphy.U$$19' Q output must be connected only to a top level output).

Assuming this issue isn't vendor-specific, should we declare those resources with the "*_n" naming style and expect the user to do the inversion themselves? Or should we keep it as-is and request the resource as raw IO?

@whitequark
Copy link
Member

@whitequark whitequark commented Jul 7, 2020

The issue with PinsN is that it gets an inverter inserted between the TRELLIS_IO instance (on ECP5 platform) and the .o exposed to the user which prevents the use of DDR primitives

Let's discuss this on IRC next time we're both online, that would be more productive I think.

@whitequark whitequark added question and removed bug labels Jul 13, 2020
@whitequark
Copy link
Member

@whitequark whitequark commented Jul 13, 2020

@whitequark whitequark closed this Jul 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants