-
Notifications
You must be signed in to change notification settings - Fork 177
Accessing input pin directly (Intel) #503
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
Comments
Use |
Ah my bad: I sort of changed what I was asking halfway through, I should edit the original question to make it a bit more clear. Basically I'm asking how you would do this on a platform with one clock: if the sync domain has already requested the default clock ("clk50", 0), how would one go about using that clock input directly (ie without an iobuf)? |
You can't. This is for a few reasons, mostly because the automatically requested clock is designed to have power-on reset logic inserted as well, which will break your PLL clocking anyway. |
Ah ok thank you, I see. I suppose it's not likely to cause a limitation as any chip with a PLL probably has multiple clock inputs anyway but that's worth knowing. |
In general you want to wire the reset of the clock domain you're driving with a PLL to the "locked" output of the PLL, not to the power-on reset. |
Got it, that would make sense for clock domain sync purposes. |
For the Stratix IV PLL (I assume it also applies to altpll in general), the input clock can't be driven by a combinational block. When instantiating a PLL, I can't find any way of driving it directly from the input pin. Using platform.request() explicitly creates a module with an altiobuf, which confuses quartus by placing buffers that get synthesised as combinational blocks (LUTs) in the clock path.
Nmigen code:
The text was updated successfully, but these errors were encountered: