<_whitenotifier-f>
[glasgow] attie opened pull request #218: applet.interface.freq_counter: implement basic frequency counter - https://git.io/JTCxQ
<d1b2>
<Attie> @whitequark - i hope that's more or less in line with what you were expecting
<d1b2>
<Attie> it seems to work well, but there is still quite a bit of aliasing on the result... a longer sample duration will start to converge on the expected frequency
<whitequark>
attie: can you split the ripple counter part into a separate PR?
<whitequark>
ah wait, i think i see what happened
<d1b2>
<Attie> where do you want the split of the three? A) platform, B) ripple counter + applet?
<whitequark>
so what you made wouldn't work as well as it should because it doesn't instantiate SB_LUT
<d1b2>
<Attie> ah, i was going to ask about that - i couldn't see where that should go, and thought you suggested doing it second
<d1b2>
<Attie> okay, thanks for the pointer... i'm not totally clear on how the LUT clean things up / makes a better signal than a straight inverter still, but I'll try and do some reading around that
<d1b2>
<Attie> and I'll move the ripple counter into platform, etc...
<whitequark>
well, a straight inverter isn't guaranteed to be glitchless
<whitequark>
a single edge on the input can produce multiple edges on the output
<whitequark>
because of the way LUTs work internally
<whitequark>
normally this is not a problem because your logic is fully synchronous
<whitequark>
but a ripple counter is an async circuit
<d1b2>
<Attie> i get metastability (which i think is what you're referring to here re multiple edges / glitches)
<whitequark>
no
<d1b2>
<Attie> but I don't get how using it as input to a LUT makes things "cleaner"
<whitequark>
i mean literally what i said
<d1b2>
<Attie> oh... the inverter itself can produce the glitches?
<whitequark>
LUTs can
<whitequark>
the toolchain does not guarantee that what it synthesizes the inverter into will be glitchless
<whitequark>
therefore, if we want a glitchless inverter, we have to make it ourselves
<whitequark>
whether or not it happens to work *right now* with your nextpnr and yosys revision is irrelevant
<whitequark>
i am not even looking at what LUT it produces because yosys is not bound by any contract to keep doing that
<d1b2>
<Attie> hm, i'm still a bit confused by this... but i'll leave you be for today
<d1b2>
<Attie> thanks for your support
<whitequark>
and fwiw i looked up the SB_LUT4 timing model
<whitequark>
I3 is indeed the fastest input to use
<d1b2>
<Attie> cool, thanks!
<_whitenotifier-f>
[glasgow] whitequark commented on pull request #218: applet.interface.freq_counter: implement basic frequency counter - https://git.io/JTWeL
<_whitenotifier-f>
[glasgow] attie commented on pull request #218: applet.interface.freq_counter: implement basic frequency counter - https://git.io/JTWe2
tomtastic has quit [Ping timeout: 240 seconds]
tomtastic has joined #glasgow
<d1b2>
<Attie> I've gone away, thought about it, read some stuff, and re-read your messages - I think I understand now
<d1b2>
<Attie> fundamentally, an "inverter" (i.e: ~clk) could be synthesized a number of ways, but there's no guarantee on what/how
<whitequark>
exactly
<d1b2>
<Attie> if we want glitch free, then we can be specific avout how to synthesize it (i.e: use a LUT, explicitly with one input changing)
<whitequark>
yep
<d1b2>
<Attie> magic, thanks!
<whitequark>
old-school digital design people love ripple counters because they do what they want in an ASIC
<whitequark>
but it's no longer true for FPGAs
<whitequark>
ah, i guess they work fine in CPLDs too
<d1b2>
<Attie> .. where in an ASIC you have much more control over the design? but in an FPGA too much is inferred to be confident?
<whitequark>
well
<d1b2>
<Attie> [btw - it's funny how re-reading your messages is much clearer after it clicked in my mind... earlier I was struggling to comprehend / follow what you were saying]
<whitequark>
if you say x <= ~x in an ASIC you can be reasonably confident it synthesizes to an inverter. this is still what i would call "implementation defined" but it's hard to imagine circumstances where it wouldn't
<sorear>
consider that a ripple counter with a register can be retimed, and the fmax of the resulting circuit is independent of length
<whitequark>
meanwhile in an FPGA you get a LUT (because you only have LUTs) and nothing inherently makes LUTs glitchless
<whitequark>
i would personally also use primitives to make one in an ASIC, but i have views on compilers that HDL programmers would consider extreme
<d1b2>
<Attie> yeah, I think we're more or less on the same page (my terminology may be lacking)
<d1b2>
<Attie> thanks again, much appreciated!
<whitequark>
np
<whitequark>
the other reason besides glitches to use an SB_LUT4 instance is using the fastest input
<whitequark>
yosys with -abc9 should do it on its own these days
<whitequark>
but it never hurts to be explicit when you *really* need it
<whitequark>
(and we do)
<d1b2>
<Attie> yep, understood :)
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
bvernoux has joined #glasgow
thasti has quit [Remote host closed the connection]
thasti has joined #glasgow
bvernoux has quit [Ping timeout: 256 seconds]
bvernoux1 has joined #glasgow
bvernoux1 has quit [Ping timeout: 272 seconds]
bvernoux has joined #glasgow
bvernoux has quit [Ping timeout: 260 seconds]
Chips4Makers has quit [Ping timeout: 240 seconds]
Chips4Makers has joined #glasgow
bvernoux has joined #glasgow
bvernoux has quit [Ping timeout: 265 seconds]
lausabass has joined #glasgow
lausabass has quit [Remote host closed the connection]
kmehall_ has quit [Remote host closed the connection]
kmehall has joined #glasgow
<whitequark>
gods, why is kicad so unpleasant to use
<whitequark>
attie: either get_dff/get_glitchless_inv should be folded into get_ripple_ff, or get_ripple_ff should not be a part of platform since it's not platform-specific
<whitequark>
in any case you misunderstood what i meant
<whitequark>
specifically, i wanted get_ripple_ff to create a single *stage* of a ripple counter
<whitequark>
because that's the smallest self-contained platform-specific unit