You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: