-
Notifications
You must be signed in to change notification settings - Fork 58
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
nextpnr does not propagate clock constraints across input buffer #200
Comments
This is not currently possible to do with nextpnr reliably because nextpnr arbitrarily discards most signal names. I've added a workaround for specifically I/O pins, but it would not work properly for something like a PLL in general. This issue should be fixed upstream in nextpnr before I would be comfortable committing to an API that constrains arbitrary signals. It should not even be necessary to define clock constraints for PLLs on ECP5, because nextpnr should be calculating the output frequency based on input frequency and PLL configuration. This functionality is not currently provided for iCE40, and once again, should be added upstream. It has been on my roadmap for a while, and although I am not the best person to add it to nextpnr, if you find its codebase too challenging to work with, let me know and I'll try to add an implementation.
This is the interesting part--since this is an IO pin, constraining it should work. Could you share your design? I'm fine with just the build directory, no need for the source. It doesn't matter at all if it's a mess, I just need to see the generated signal names for IOs and figure out what went wrong there. |
The ECP5 one in a single file: For the iCE40 case, examples/board/blinky.py will reproduce it. I don't mind trying to add PLL output frequency calculation in nextpnr, but it may be a while before I get to it. |
Interesting. So the constraints do work correctly on pins:
... but for some reason this never propagates to the clock domain:
... even though it's (almost) directly connected in netlist:
I feel like this is a nextpnr issue. Could you report it upstream? |
Oh yeah, and I suspect the reason your other clocks aren't constrained properly is because nextpnr can't propagate frequencies across |
Interestingly, it does properly propagate clocks across |
I narrowed it down to the clock constraint not being propagated across the input buffer. |
This was fixed upstream in nextpnr. YosysHQ/nextpnr#324 |
I'm getting all clocks set to 12 MHz for timing purposes in nextpnr, both for iCE40 and ECP5. I could be missing something.
I looked into fixing it myself, but it's probably beyond me without some guidance.
top.lpf:
ssclk_0__io is $glbnet$clk and the other two are generated by a PLL from host_0__hdc__p.
if I pass this python script to nextpnr with
--pre-pack
, I get correct clock frequencies.I'm not sure how reliable this naming will be, but it seems stable with both of my nextpnr designs.
I'd really like to be able to do
platform.add_clock_constraint(ClockSignal("c125"), 125e6)
or similar in the module where the generated clocks originate. It would be nice to eventually create a library module from the EHXPLLL and other ECP5 clock producing components that would handle all of this automatically like Vivado does.Possibly related:
#88, #71
I did a pull and rebuild on nextpnr yesterday:
I can clean up and publicly share this design if that would be helpful. It's a mess right now as I just started converting from Verilog + Diamond.
The text was updated successfully, but these errors were encountered: