01:40 <_whitenotifier-b> [whitequark/Boneless-CPU] tpwrules pushed 2 commits to master [+0/-0/±2] https://git.io/JJ1us

01:40 <_whitenotifier-b> [whitequark/Boneless-CPU] tpwrules 56e55b4 - test.test_core: patch to use generator functions for latest nmigen

01:40 <_whitenotifier-b> [whitequark/Boneless-CPU] tpwrules bdf1eef - gateware.core: process EXTI in 1 cycle instead of 4

02:37 <awygle> daveshah: the high speed i/o interface app note, tn-02035, says the 1x geared s-clk blocks must be used for speeds below 250 MHz, and the 2x geared e-clk blocks must be used for speeds above 400 MHz. does that mean in between i can use either one?

02:42 <whitequark> i'm curious what's the problem with using e-clk at speeds that are too low

02:42 <whitequark> ah, wait, i think i know

02:43 <whitequark> i bet it's the thing where edge-aligned/center-aligned sampling is faked with some silicon delay lines

02:44 <awygle> probably, yeah

02:44 <whitequark> can we talk about how much of a bullshit solution it feels?

02:44 <whitequark> i haven't used it so i don't know if it actually doesn't work in some practical case

02:44 <whitequark> but it seems so ugly

02:45 <awygle> i honestly don't know what else you could do though

02:45 <whitequark> there's the obvious disadvantages of a PLL, yes

02:45 <whitequark> but... diamond doesn't even seem to adjust the delay line tap for the frequency you request?

02:45 <whitequark> "here are some tap numbers i think are good. do you like this"

02:45 <awygle> hm, that i don't know

02:46 <awygle> i have used the explicitly-adjustable delay line primitive thingy. delayf or whatever it is

02:46 <awygle> but i haven't paid enough attention to see if the center alignment delay thingy changes based on frequency

02:47 <awygle> i'm saying thingy too much.

02:47 <whitequark> "thingy" is a good name for all the weird blocks fpgas have :p

02:47 <awygle> why are these pictures so shit

02:48 <whitequark> awygle: can you remind me what the parameter was called?

02:48 <awygle> DEL_MODE?

02:48 <whitequark> ah yes

02:48 <whitequark> awygle: https://github.com/YosysHQ/nextpnr/blob/c0901fb972e34d2d16b3ac0074a18542ba1c448d/ecp5/pack.cc#L1964-L1988

02:48 <whitequark> daveshah says this is the exact same thing diamond does and i trust him on that

02:49 <whitequark> but it makes no sense to me. i don't know how it can possibly work on any nontrivial range of frequencies

02:50 <awygle> that's interesting and also weird

02:50 <awygle> this picture shows a lot more going on

02:50 <awygle> but any or all of it could be lies of course

02:51 <awygle> it claims there are DLLs

02:51 <awygle> which, like, yeah, that's what i'd expect

02:52 <awygle> i wonder if that's just the static clock injection time

02:52 <whitequark> awygle: section 8.4 seems to imply that

02:53 <awygle> ah yeah, ok so that makes sense

02:53 <awygle> so not nearly as hacky as it sounds lol

02:53 <whitequark> okay, then i think i don't understand how it works

02:53 <whitequark> can you explain?

02:53 <awygle> look at figure 5.3

02:54 <awygle> as a representative example

02:54 <whitequark> sure

02:55 <awygle> the DLLDELD and its control block DDRDLLA do the frequency-dependent parts

02:55 <awygle> but the clock going through all of those extra elements adds a certain amount of delay to it, which does not depend on frequency

02:55 <awygle> so the DELAYG statically delays the data by that same amount to keep them in sync

02:56 <whitequark> ohh, this clears things up a lot

02:56 <awygle> probably some more static delay stuff in there to deal with setup/hold and whatnot too

02:56 <whitequark> but i don't understand one more thing

02:57 <whitequark> ... oh

02:57 <whitequark> aligned and centered simply have different topologies.

02:57 <awygle> yup

02:57 <whitequark> ok, i completely misunderstood what they were doing there

02:57 <whitequark> going to our original topic: what prevents using eclk at low bit rates?

02:58 <whitequark> since it's not the DELAYF/G blocks

02:58 <awygle> yeha idk. ECLKSYNCB for some reason?

02:59 <awygle> that's the only new block

03:00 <whitequark> wait

04:23 <awygle> hm, in nextpnr i get "Derived frequency constraint of 103.3 MHz for net sram_clk", and then a couple lines later "Annotating ports with timing budgets for target frequency 12.00 MHz". can someone explain the apparent conflict? i only have the one clock in this design

06:12 <tnt> awygle: Derived is probably from a PLL.

14:00 <implr> anyone bought/used a LiteFury?

14:00 <implr> cheap

14:00 <implr> and has schematics on github as opposed to weird aliexpress boards

14:41 <zyp> implr, there's also the cle-215+ that goes cheap on ebay nowadays, which is a rebranded nitefury

14:42 <zyp> I've got one of those