whitequark changed the topic of #amaranth-lang to: Amaranth hardware definition language · code https://github.com/amaranth-lang · logs https://libera.irclog.whitequark.org/amaranth-lang
bvernoux has quit [Quit: Leaving]
<_whitenotifier-e> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/nextpnr/compare/5aa691fbc868...a15ec6cabfa8
<_whitenotifier-e> [YoWASP/nextpnr] whitequark a15ec6c - Update dependencies.
Degi has quit [Ping timeout: 256 seconds]
Vonter has quit [Ping timeout: 256 seconds]
Degi has joined #amaranth-lang
Vonter has joined #amaranth-lang
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
lf has quit [Ping timeout: 245 seconds]
lf has joined #amaranth-lang
<_whitenotifier-e> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/yosys/compare/5654c3d90852...d04531679af3
<_whitenotifier-e> [YoWASP/yosys] whitequark d045316 - Update dependencies.
bl0x_ has quit [Ping timeout: 245 seconds]
bl0x_ has joined #amaranth-lang
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #amaranth-lang
toshywoshy has quit [Read error: Connection reset by peer]
toshywoshy has joined #amaranth-lang
emeb_mac has quit [Ping timeout: 256 seconds]
Sarayan has quit [Remote host closed the connection]
Sarayan has joined #amaranth-lang
Lilian has quit [Quit: ZNC 1.8.2 - https://znc.in]
Lilian has joined #amaranth-lang
Lilian has quit [Client Quit]
Lilian has joined #amaranth-lang
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #amaranth-lang
Lilian has quit [Quit: ZNC 1.8.2 - https://znc.in]
Lilian has joined #amaranth-lang
Lilian has quit [Quit: ZNC 1.8.2 - https://znc.in]
Lilian has joined #amaranth-lang
Lilian has quit [Quit: ZNC 1.8.2 - https://znc.in]
Lilian has joined #amaranth-lang
Vonter has quit [Ping timeout: 240 seconds]
bvernoux has joined #amaranth-lang
Vonter has joined #amaranth-lang
Vonter has quit [Ping timeout: 250 seconds]
<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]
<d1b2> <dave berkeley> https://pastebin.com/vubu7Gbk
<d1b2> <dave berkeley> The ECP5PLL Instance params are : ECP5PLL {'ifreq': 25000000.0, 'ofreq': 48000000.0, 'clki_div': 5, 'clkfb_div': 96, 'clko0_div': 10, 'vco': 480000000.0, 'clkfb': 0} {'i_RST': (sig rst), 'i_CLKI': (sig clkin), 'i_STDBY': (sig stdby), 'o_LOCK': (sig locked), 'p_FEEDBK_PATH': 'INT_OP', 'p_CLKFB_DIV': 96, 'p_CLKI_DIV': 5, 'o_CLKINTFB': (sig clkfbout), 'i_CLKFB': (sig clkfbin), 'p_CLKOP_ENABLE': 'ENABLED', 'p_CLKOP_DIV': 10,
<d1b2> 'p_CLKOP_FPHASE': 0, 'p_CLKOP_CPHASE': 0, 'o_CLKOP': (sig $signal)}
<d1b2> <dave berkeley> fin=25MHz / 5 == 5Mhz. 5 * 96 == vco=480MHz, vco/10 = 48MHz. Which looks correct to me.
<agg> what's actually getting set as the attributes and parameters on the pll?
<miek> the clkop divider is included in the feedback loop, so that's where the extra factor of 10 is coming from
<agg> you want FREQUENCY_PIN_CLKI and FREQUENCY_PIN_CLKOP as attributes, and CLKI_DIV, CLKFB_DIV as parameters
<agg> ah, yea, that will do it
<d1b2> <dave berkeley> Ah, okay, so the tools know what is going on, but I don't! Thanks. I'll take another look.
<agg> have you seen the ecppll command-line tool? `ecppll -i 25 -o 48` says to use clkfb_div=15 clkop_div=13 clki_div=8
<miek> fig 23 from TN1263 shows it: https://i.imgur.com/aEd5XzI.png
<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.
<_whitenotifier-e> [amaranth] modwizcode opened issue #683: `AsyncFIFO` removes data from read domain during read reset - https://github.com/amaranth-lang/amaranth/issues/683
<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
<Degi> (25 ps vs 18 ps)
<Degi> (And cannot be sampled all at once)
bvernoux has quit [Quit: Leaving]