<d1b2>
<dave berkeley> I'm trying to replace the "sync" Clock Domain with a PLL derived clock, on an ECP5. I think I have the PLL calculations correct and the wiring correct, but the tools fail with "ERROR: Max frequency for clock '$glbnet$clk': 98.36 MHz (FAIL at 480.08 MHz)". My VCO frequency is 480MHz, and this is divided down by 10 to 48MHz. I can't see how to let the tools know what frequency my clock is. Is there something like an attribute I can
<d1b2>
set on the clock domain, or a parameter I can output to the tools?
<d1b2>
<dave berkeley> "Info: Generating derived timing constraints... Info: Input frequency of PLL 'U$$0.U$$0' is constrained to 25.0 MHz Info: Derived VCO frequency 4807.7 MHz of PLL 'U$$0.U$$0' is out of legal range [400MHz, 800MHz] Info: Derived frequency constraint of 480.1 MHz for net clk" The derived VCO frequency seems wrong to me. I had this clock (vco=480MHz / 10) driving a separate domain and it looked good.
<miek>
could you pastebin your pll instance code?
Abhishek_ has quit [Quit: Connection closed for inactivity]
<agg>
and also suggests you can't achieve exactly 48M out from a 25M input :/
<d1b2>
<dave berkeley> Ah yes, the /10 is in the feedback loop. Thanks. I'll fix the calc() function.
<d1b2>
<dave berkeley> I wasn't aware of ecppll, thanks.
<miek>
i suppose you can achieve it if it's ok to use another output, `ecppll -i 25 -o 240 --clkout1 48` finds a solution
<d1b2>
<dave berkeley> Yes, I can see how using a different clock as the output would increase the options. I need to look at my code again. Impressed that the tools knew the VCO and domain freqs.
<d1b2>
<dave berkeley> I see what I was doing wrong. I was not checking that the input to the freq/phase discriminator was within valid range, so it was finding solutions for frequencies that would not work correctly. The ecppll source made this clear.
bvernoux has quit [Quit: Leaving]
bvernoux has joined #amaranth-lang
emeb_mac has joined #amaranth-lang
<Degi>
agg: I guess it depends on how far out of spec you want to be, but with CLKI = 25 and CLKFB = 48 and CLKO = 10 it should work fine
<Degi>
Hmm, I wonder if you could just make 24 MHz with 0° and 180° and XOR it together to get 48 MHz
<cr1901>
I don't think LUTs are guaranteed to be glitchless
<cr1901>
(i.e. the XOR part would go thru a LUT)
<Degi>
Yes, it might not work maybe
<d1b2>
<Herr Brain> LUTs are internally implemented as SRAM I believe. But yeah don't do clock multiplication using FPGA fabric like that.
<Degi>
I mean you can do lots of funny things with LUTs, especially if instantiated directly. Maybe even a digital PLL (like varying the length of a delay line by predefined steps) could be possible
<d1b2>
<Herr Brain> FPGAs are very good at implementing synchronous logic, and they generally have separate dedicated pathways/buffers for clock and data. It may be possible to connect them, but that doesn't make it a good idea.
<Degi>
Eh, you can make several hundred elements long delay lines and use that as a lowpass filter (signals beyond a GHz or so don't reach the end) (at least I did that once)
<d1b2>
<Herr Brain> Again, it's possible to do that, but it doesn't mean it's a good idea (outside of a lab setting).
<Degi>
That's why my programs like that get a warning note, since sometimes they run the FPGA several times over frequency spec
<d1b2>
<Herr Brain> Keep in mind that some modern FPGAs actually have programmable delay lines as part of the I/O pin logic.
<d1b2>
<Herr Brain> Yep, sounds about right.
<Degi>
On the ECP5 5G thats slower than LUT to LUT dealy